IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

Integrating the Health Care EnterpriseIHE IT Infrastructure (ITI)
Technical Framework
Volume 1(ITI TF-1)
Integration Profiles

IHE IT 基盤（ITI TF-1）
テクニカルフレームワーク

第一巻

Revision 10.0 - Final Text

Septenber 27, 2013________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

1

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

1. 前書き ................................................................................................................................................... 12
1.1 テクニカルフレームワークの概観 .................................................................................... 12
1.2 IT 基盤テクニカルフレームワーク第 1 巻の概観.............................................................. 13
1.3 想定読者 ............................................................................................................................ 13
1.4 標準規格との関係 ............................................................................................................. 14
1.5 実製品との関係 ................................................................................................................. 14
1.6 凡例 .................................................................................................................................. 15

1.6.1 アクタとトランザクション図および表 ...................................................................... 15
1.6.2 処理流れ図 ................................................................................................................. 15
1.6.3 テクニカルフレームワークの相互参照...................................................................... 16
1.7 本年に導入された変更の範囲 ........................................................................................... 16
1.8 保安面との関係 ................................................................................................................. 19
1.9 注釈 ................................................................................................................................... 20
1.10 著作権許諾 ...................................................................................................................... 20
1.11 IHE テクニカルフレームワークの開発、維持手順 ......................................................... 20
2. IT 基盤統合プロファイル ................................................................................................................... 22
2.1 統合プロファイル間の依存関係 ........................................................................................ 22
2.2 統合プロファイルの概観................................................................................................... 24

2.2.1 本節は予約済み ........................................................................................................ 25
2.2.2 本節は予約済み ........................................................................................................ 25
2.2.3 表示用情報取得（Retrieve Information for Display, RID） ................................... 25
2.2.4 施設使用者認証（Enterprise User Authentication, EUA） ................................... 25
2.2.5 患者識別相互参照（Patient Identifier Cross-referencing, PIX） ........................... 26
2.2.6 患者同期下アプリケーション（Patient Synchronized Applications, PSA） .......... 26
2.2.7 時刻一貫性 （Consistent Time, CT） .................................................................... 26
2.2.8 患者基本情報問合せ（Patient Demographics Query, PDQ） .................................. 26
2.2.9 監査追跡と拠点認証（Audit Trail and Node Authentication, ATNA）.................. 26
2.2.10 施設間書類共有（Cross-Enterprise Document Sharing, XDS） .......................... 27
2.2.11 職員録（Personnel White Pages, PWP） ............................................................... 27
2.2.12 この節は、書類可用性通知（NAV）に予約済 ........................................................ 27
2.2.13 施設間使用者認証プロファイル（Cross-Enterprise User Assertion, XUA） ....... 27
2.2.14 患者管理（Patient Administration Management, PAM） ................................... 28
2.2.15 施設間高信頼書類交換（XDR）............................................................................... 28
2.2.16 施設間書類媒体交換（Cross-Enterprise Document Media Interchange, XDM） 28
2.2.17 データ収集用紙取得（Retrieve Form for Data Capture, RFD） .......................... 28________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

2

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

2.2.l8 共同体間情報利用（Cross-Community Access, XCA） ........................................... 28
2.2.19 基本患者プライバシ同意（Basic Patient Privacy Consents, BPPC） .................. 29
2.2.20 スキャン書類共有（XDS-SD） ................................................................................ 29
2.2.21 この節は予約済です................................................................................................. 29
2.2.22 この節は予約済です................................................................................................. 29
2.2.23 患者識別相互参照（Patient Identifier Cross-referencing HL7 V3, PIX V3） ...... 29
2.2.24 患者基本情報問合せ（Patient Demographics Query HL7 V3, PDQV3） ............. 30
2.2.25 複数患者問合せ（Multi-Patient Queries, MPQ） ................................................. 30
2.3 製品への実装 PRODUCT IMPLEMENTATIONS ................................................................... 30
3 表示用情報取得（Retrieve Information for Display, RID） ........................................................... 31
3.1 実行役・トランザクション ............................................................................................... 32
3.2 表示用情報取得（RID）統合プロファイルのオプション ................................................. 33
3.3 表示用情報取得の処理流れ ............................................................................................... 34
4. 施設使用者認証（Enterprise User Authentication,

EUA） ........................................................ 37

4.1 実行役・トランザクション ............................................................................................... 38
4.2 施設使用者認証統合プロファイルのオプション .............................................................. 40
4.3 施設使用者認証プロファイル処理 .................................................................................... 40

4.3.1 基本使用者認証処理ながれ ........................................................................................ 40
4.3.2 使用者認証と使用者同期アプリケーション処理流れ ................................................ 42
4.3.3 複数アプリケーションでの迅速使用者切り替え処理流れ ......................................... 43
5. 患者識別相互参照（Patient Identifier Cross-Referencing, PIX）................................................. 45
5.1 実行役/トランザクション.................................................................................................. 47
5.2 患者識別相互参照統合プロファイルオプション .............................................................. 47

5.2.1 小児基本情報 ............................................................................................................. 48
5.3 患者識別相互参照プロファイル処理流れ ......................................................................... 49

5.3.1 使用例: 一施設内に複数の患者識別圏 ...................................................................... 49
5.3.2 使用例: 連携施設間での複数患者識別圏 ................................................................... 50
5.3.3 小児基本情報オプション使用例 ................................................................................ 51
5.4 PIX 統合プロファイルと EMPI の関係 ............................................................................. 52
6. 患者同期アプリケーション（Patient Synchronized Applications, PSA） ................................... 54
6.1 実行役・トランザクション ............................................................................................... 54
6.2 患者同期アプリケーション統合プロファイルオプション ................................................ 55
6.3 患者同期アプリケーション統合プロファイル処理流れ .................................................... 55________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

3

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

6.3.1 使用例: 単純切替 ....................................................................................................... 55
7 時刻一貫性（Consistent Time, CT） .................................................................................................. 57
7.1 実行役・トランザクション ............................................................................................... 57
7.2 時刻一貫性統合プロファイルオプション ......................................................................... 58
7.3 時刻一貫性処理流れ .......................................................................................................... 58
8 患者基本情報問合せ（Patient Demographics Query, PDQ） ........................................................ 60
8.1 実行役・トランザクション ............................................................................................... 60
8.2 患者基本情報問合せ統合プロファイルオプション ........................................................... 61

8.2.2 小児基本情報 （訳者注: 節番号は 8.2.1 が正しい？） .......................................... 61
8.3 患者基本情報問合せ処理流れ ............................................................................................ 62

8.3.1 IHE の他の業務流れプロファイルと PDQ の組み合わせ使用 .................................. 64
8.3.2 供給役データ設定 ...................................................................................................... 64
9 監査追跡と拠点認証（Audit Trail and Node Authentication, ATNA） ......................................... 65
9.1 認証 ................................................................................................................................... 66

9.1.1 使用者認証 ................................................................................................................. 66
9.1.2 接続認証 ..................................................................................................................... 66
9.2 監査追跡 ............................................................................................................................ 67

9.2.1 監査通信文 ................................................................................................................. 68
9.2.2 後方互換性 ................................................................................................................. 70
9.3 監査追跡のサポート .......................................................................................................... 70
9.4 実行役とトランザクション ............................................................................................... 71
9.5 ATNA 統合プロファイルオプション ................................................................................. 73

9.5.1 ATNA 暗号化オプション （退役） ......................................................................... 73
9.5.2 放射線監査追跡オプション ........................................................................................ 73
9.6 監査追跡と拠点認証処理流れ ............................................................................................ 73

9.6.1 正常拠点処理流れ ...................................................................................................... 74
9.6.2 非認証拠点での処理流れ ........................................................................................... 75
9.6.3 非認証使用者の処理流れ ........................................................................................... 76
9.7 安全拠点、安全アプリケーション、他の実行役の関係 ................................................... 77
10. 施設間書類共有（Cross-Enterprise Document Sharing, XDS.b） .............................................. 79
10.1 実行役とトランザクション ............................................................................................. 81

10.1.1 実行役 ...................................................................................................................... 82
10.1.2 トランザクション .................................................................................................... 83________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

4

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

10.1.3 XDS 書類内容サポート............................................................................................ 84
10.2 統合プロファイルオプション ......................................................................................... 85

10.2.1 書類置き換えオプション ......................................................................................... 86
10.2.2 書類追補オプション................................................................................................. 86
10.2.3 書類変換オプション................................................................................................. 86
10.2.4 フォルダ管理オプション........................................................................................ 87
10.2.5 非同期インターネットサービス交換オプション ..................................................... 87
10.3 統合プロファイル処理流れ ............................................................................................. 87
10.4 一般的原則 ...................................................................................................................... 91

10.4.1 EDR-CR 構想 .......................................................................................................... 91
10.4.2 XDS 書類構想 ........................................................................................................ 92
10.4.3 書類提出要求 ........................................................................................................... 93
10.4.4 提出セットの構想 .................................................................................................... 94
10.4.5 フォルダの構想 ........................................................................................................ 94
10.4.6 提出要求、提出セットとフォルダ使用の実例 ......................................................... 95
10. 4.7 XDS 登録所のデータモデルと属性 ......................................................................... 96
10.4.8 XDS 連携圏の構想 .................................................................................................... 98
10.4.9 患者識別情報管理 .................................................................................................... 99
10.4.10 書類の生活史 ....................................................................................................... 100
10.4.11 書類問合せ ........................................................................................................... 102
10.5 実装戦略 ........................................................................................................................ 102
10.6 患者識別通信要求事項 ................................................................................................. 104
10.7 安全の考慮 .................................................................................................................... 105
11 職員録（Personnel White Pages, PWP） ...................................................................................... 108
11.1 実行役・トランザクション ........................................................................................... 108
11.2 PWP 統合プロファイルオプション ............................................................................... 109
11.3 PWP 統合プロファイル処理流れ .................................................................................. 109
12 この節は書類可用性通知（NAV）のため予約されています。 ................................................ 110
13 施設間使用者断定（XUA）統合プロファイル ........................................................................... 111
13.1 使用例 ........................................................................................................................... 112
13.2 XUA の開発 ................................................................................................................... 113
13.4 実行役・トランザクション ........................................................................................... 114
13.5 オプション .................................................................................................................... 115
13.6 群形成 ........................................................................................................................... 115________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

5

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

13.6.1 監査追跡拠点認証 (ATNA) .................................................................................. 115
13.6.2 施設間書類共有（Cross-Enterprise Document Sharing, XDS） ...................... 115
13.6.3 施設使用者認証（Enterprose User Authentication, EUA） ............................. 116
13.6.4 ITI TF-2x: 付録Ｖに影響するウエッブサービストランザクション ................... 116
13.7 処理流れ ........................................................................................................................ 117
13.8 安全の考慮 .................................................................................................................... 117
14 患者入院管理（PAM）統合プロファイル ................................................................................... 118
14.1 患者入院管理使用例 ...................................................................................................... 118
14.2 患者識別管理使用例 ...................................................................................................... 118

14.2.1 患者受診情報管理使用例 ....................................................................................... 118
14.2.2 実行役・トランザクション .................................................................................... 119
14.3 患者入院管理統合プロファイルオプション.................................................................. 119

14.3.1 融合オプション（Merge Option） ....................................................................... 121
14.3.2 Link/Unlink オプション（Link/Unlink Option） ................................................ 121
14.3.3 入・外来患者受診管理オプション（Inpatient/Outpatient Encounter Management
Option） ............................................................................................................................ 121
14.3.4 中断事例管理オプション（Pending Event Management Option） .................... 121
14.3.5 高度受診管理オプション（Advanced Encounter Management Option） .......... 121
14.3.6 一時的患者転送追跡オプション（Temporary Patient Transfer Tracking Option）........................................................................................................................................... 121
14.3.7 移動履歴オプション（Historic Movement Option） ........................................... 121
14.4 患者入院管理統合プロファイル実行役の群形成 .......................................................... 122

14.4.1 患者受診供給役の実行役群形成 ............................................................................ 122
14.4.2 ほかの IHE 実行役の群形成 .................................................................................. 122
14.5 患者入院管理処理流れ ................................................................................................. 123

14.5.1 患者識別管理 ......................................................................................................... 123
14.5.2 患者受診情報管理 . 124 図 14.5-7 PAM プロファイルでの一時移動追跡処理ながれ
15 XDR 統合プロファイル ................................................................................................ 130
15 XDR 統合プロファイル ................................................................................................................... 131
15.1 実行役・トランザクション ........................................................................................... 131
15.2 統合プロファイルオプション ....................................................................................... 132

15.2.1 意図的に空白 ......................................................................................................... 132
15.2.2 基本患者プライバシ強化オプション ..................................................................... 132
15.3 XDR 処理流れ................................................................................................................ 132
15.4 デジタル通信................................................................................................................. 133________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

6

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

15.5 安全の考慮 .................................................................................................................... 133
16 施設間書類媒体交換統合プロファイル ........................................................................................ 134
16.1 実行役・トランザクション ........................................................................................... 134
16.2 XDM 統合プロファイルオプション .............................................................................. 135

16.2.1 USB オプション ..................................................................................................... 136
16.2.2 CD-R オプション .................................................................................................... 136
16.2.3 電子メール付属 ZIP（ZIP over Email） .............................................................. 136
16.2.4 電子メール付属 ZIP 応答（ZIP over Email Rsponse） ........................................ 136
16.3 XDM 処理流れ ............................................................................................................... 136
16.4 デジタル通信................................................................................................................. 138

16.4.1 実際の媒体タイプ .................................................................................................. 138
16.4.2 ネットワーク上の仮想媒体 .................................................................................... 138
16.4.3 媒体の内容 ............................................................................................................. 138
16.5 安全の考慮 .................................................................................................................... 139
17 データ収集用紙回収（Retrieve Form for Data Capture） ......................................................... 139
17.1 使用例 ........................................................................................................................... 140

17.1.1 探索的新薬治験の使用例 ....................................................................................... 140
17.1.2 望ましい状態 ......................................................................................................... 142
17.1.3 薬物監視シナリオ .................................................................................................. 144
17.2 実行役・トランザクション ........................................................................................... 144

17.2.1 実行役 .................................................................................................................... 145
17.2.2 トランザクション .................................................................................................. 146
17.3 データ取得用紙回収のオプション ................................................................................ 146

17.3.1 用紙保存オプション............................................................................................... 147
17.3.2 データ説明書オプション ....................................................................................... 147
17.3.3 XForms オプション ................................................................................................ 147
17.4 データ取得用紙回収処理流れ ....................................................................................... 147
17.5 安全の考慮 .................................................................................................................... 151

17.5.1 RFD リスク分析とリスク評価 ............................................................................... 151
17.5.2 推奨 ........................................................................................................................ 152
18 共同体間利用（XCA）統合プロファイル ................................................................................... 153
18.1 実行役・トランザクション ........................................................................................... 153
18.2 XCA 統合プロファイルオプション ............................................................................... 154

18.2.1 XDS 連携圏オプション .......................................................................................... 155________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

7

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

18.2.2 非同期ウェッブサービス交換オプション .............................................................. 155
18.2.3 群形成のルール ...................................................................................................... 155
18.3 XCA 処理流れ ................................................................................................................ 157

18.3.1 使用例 .................................................................................................................... 157
18.3.2 homeCommunityId 定義 ..................................................................................... 157
18.3.3 詳細な連携 ............................................................................................................. 158
18.4 XCA 安全考慮 ................................................................................................................ 161

18.4.1 XCA リスク分析とリスク評価 ............................................................................... 161
18.4.2 推奨 ........................................................................................................................ 162
18.4.3 基本方針の選択 ...................................................................................................... 163
19 基礎患者プライバシ承諾（Basic Patient Privacy Consents, BPPC）統合プロファイル ....... 164
19.1 基本患者プライバシ承諾使用例 .................................................................................... 165

19.1.2 紙署名 .................................................................................................................... 166
19.1.3 高度患者プライバシ承諾 ....................................................................................... 167
19.2.1 基本方針作成、公表のまとめ ................................................................................ 169
19.3 実行役とトランザクション ........................................................................................... 169

19.3.1 群形成 .................................................................................................................... 170
19.4 基本患者プライバシ承諾プロファイルオプション ....................................................... 170

19.4.1 意図的に空白のままです。 .................................................................................... 171
19.4.2 意図的に空白のままです。 ..................................................................................... 171
19.4.3 基本患者プライバシ承諾オプション ..................................................................... 171
19.4.4 スキャン書類付基本患者プライバシ承諾オプション ............................................. 171
19.4.5 患者プライバシ承諾閲覧オプション ..................................................................... 171
19.5 意図的に空白のまま ...................................................................................................... 171
19.6 XDS 連携圏での BPPC 処理流れ .................................................................................. 171

19.6.1 プライバシ方針患者承諾のチエック ..................................................................... 172
19.6.2 患者のプライバシ方針承諾の記録 ......................................................................... 172
19.6.3 承諾方針に照らしての書類の公表 ......................................................................... 172
19.6.4 公表された書類の使用 ........................................................................................... 172
19.7 安全の考慮 .................................................................................................................... 173
20 スキャン書類内容の施設間共有統合プロファイル .................................................................... 174
20.1 使用例 ........................................................................................................................... 174

20.1.1 内容使用例 ............................................................................................................. 174
20.1.2 内容生成使用例 ...................................................................................................... 175
20.1.3 内容消費役使用例 .................................................................................................. 176________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

8

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

20.2 実行役とトランザクション ........................................................................................... 176
20.3 スキャン書類内容統合プロファイルオプション .......................................................... 176
20.4 スキャン画像 XDS、XDR、XDM 結合 ........................................................................ 177
20.5 スキャン処理内容処理流れ ........................................................................................... 177
21 値セット共有統合プロファイル（SVS） ..................................................................................... 178
21.1 実行役・トランザクション ........................................................................................... 178

21.1.3 IT SVS と CTS の関係 ........................................................................................... 181
21.2 SVS 統合プロファイルオプション ................................................................................ 187

21.2.1 多値セットの取得 .................................................................................................. 187
21.3 SVS 処理流れ ................................................................................................................ 187

21.3.1 流れ全体の概観 ...................................................................................................... 188
21.3.2 使用例 .................................................................................................................... 189
21.4 SVS 安全考慮 ................................................................................................................ 196
22 書類依拠紹介要求統合（Document-based Referral Request, DPR）プロファイル ............... 197
23 患者識別相互参照 HL7 V3（PIXV3） ......................................................................................... 197
23.1 実行役・トランザクション ........................................................................................... 197
23.2 患者識別相互参照 HL7 V3 統合プロファイルオプション ............................................ 198

23.2.1 小児基本情報 .......................................................................................................... 199
23.3 患者識別相互参照 HL7 V3 統合プロファイル処理流れ ................................................ 200
23.4 PIXV3 統合プロファイルと EMPI との関係 ................................................................. 200
23.5 患者識別子通信要求事項 .............................................................................................. 200
23.6 安全の考慮 .................................................................................................................... 200
24 患者基本情報問い合わせHL7 V3 （PDQV3) .......................................................................... 201

24.1 実行役・トランザクション ........................................................................................... 201
24.2 患者基本情報問い合わせ HL7 V3 統合プロファイルオプション ................................ 201

24.2.1 継続 ........................................................................................................................ 202
24.2.2 小児基本情報 .......................................................................................................... 202
24.3 患者基本情報問い合わせ HL7 V3 統合プロファイル処理流れ ..................................... 203

24.3.1 PDQV3 と他の IHE 業務流れプロファイルとの組み合わせ使用 .......................... 203
24.3.2 供給者データ設定 .................................................................................................. 203
24.4 意図的に空白のまま ...................................................................................................... 203
24.5 安全考慮 ........................................................................................................................ 203
25 多患者問い合わせ（MPQ） ........................................................................................................... 205________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

9

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

25.1 実行役・トランザクション ........................................................................................... 205
25.2 多患者問い合わせ統合プロファイルオプション .......................................................... 205

25.2.2 非同期ウェッブサービス交換オプション .............................................................. 206
25.3 MPQ 処理流れ ............................................................................................................... 206
25.4 使用例 ........................................................................................................................... 206

25.4.1 公衆衛生での多患者問い合わせ ............................................................................ 206
25.5 安全考慮 ........................................................................................................................ 208
26 予約済み ............................................................................................................................................ 210
付録 A:

実行役の説明 ...................................................................................................................... 212

付録 B: トランザクションの説明 .................................................................................................... 215
付録 C:

IHE 統合宣言 ....................................................................................................................... 219

C.1 IHE 統合宣言の構造と内容 ............................................................................................ 219
C.2 IHE 統合宣言の書式 ....................................................................................................... 220
付録 D:

使用者認証技術－パスワード、生体計測、および、トークン ..................................... 221

付録 E: プロファイル間連携の考慮 ................................................................................................. 222
E.1 RID, EUA と PIX 統合プロファイルの組み合わせ使用 ................................................. 222
E. 2 と XDS と RID の統合 ................................................................................................... 222
E. 3 XDS と PIX の統合 ........................................................................................................ 222
E. 4 XDS と PWP の統合 ...................................................................................................... 223
E. 5 XDS と PDQ の統合 ....................................................................................................... 223
E. 6 XDM と XDS, 内容統合プロファイル、PIX、DSG との統合 ...................................... 223
E.7 XDM/XDR の区別 ........................................................................................................... 224
E. 8 XDR と XDS、内容統合プロファイル、PIX、DSG との統合 ...................................... 224
E.9 XCA と XDS および非 XDS 共同体との統合 ................................................................. 225
E. 10 XCA と患者識別管理.................................................................................................... 227
E.10.1 PIX を使用した患者識別 ........................................................................................... 227
付録 F:

標準作成組織への要望 ......................................................................................................... 229

付録 G: 安全の考慮 ............................................................................................................................ 229
付録 H: 意図的に空白のままです。................................................................................................. 231
付録 I:

意図的に空白のままです。 ................................................................................................. 231

付録 J:

XDS 文書の内容と形式 ........................................................................................................ 231________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

10

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________付録 K:

XDS 構想の詳細 .................................................................................................................. 233

K.1 XDS 文書の構想.............................................................................................................. 233
K.2 XDS 連携圏構想.............................................................................................................. 234
K.3 XDS の他の原理.............................................................................................................. 235
K.4 書類の同定 ..................................................................................................................... 235
K.5 書類の関係例 .................................................................................................................. 236
付録 L:

XDS 連携圏定義のチェック表 ........................................................................................... 237

付録 M: 施設間書類共有と IHE 道程.............................................................................................. 238
M.1 XDS の書類内容統合プロファイル .............................................................................. 238
M.2 施設間動的情報共有 ..................................................................................................... 238
M.3 共同業務流れ処理管理 ................................................................................................. 238
M.4 安全とプライバシー管理 .............................................................................................. 238
M.5 XDS 連携圏の連合 ......................................................................................................... 238
付録 N:

意図的に空白のままです。 ................................................................................................ 239

付録 O: 意図的に空白のままです。................................................................................................ 239
付録 P: プライバシ利用方針（情報的内容） ................................................................................ 240
P.1 機微と記された場合の承諾と役割に基づく利用制限 ..................................................... 241
P.3 実装に考えられるチエック表 ......................................................................................... 242
P.4 あり得る義務 ................................................................................................................... 243
P.5 動的使用例 ...................................................................................................................... 244
用語集 ...................................................................................................................................................... 245________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

11

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

1. 前書き医療機関情報統合（IHE）は最新の医療施設を支える情報システムの統合を奨励すべく企画された、先導的活動です。基本的な目的は、患者の診療にあたっては、医学的判断に必要な全ての情報が、正確で医療専門家にいつでも利用可能であるようにすることです。IHE
先導的活動は情報統合の努力を奨励する過程であり、公開討論の場です。特定の臨床上の目的を達成するため、確立された通信文規格を実装する際の技術的枠組み（テクニカルフ
レームワーク）です。この枠組みの実装に課す厳格な試験手続きが IHE にはあります。この枠組みの有用性を示し、その企業や販売社による適用を奨励するため、主要な医療専門家の集会で教育セッションや展示を組織しています。
IHE 先導的活動で使われる実現方法は、新しい標準を定めることでなく、むしろ既存の標準、たとえば、HL7、ASTM、DICOM、ISO、IETF、OASIS、および他の適切な規格の使用を支えることです。IHE プロファアイルは、これらの規格が該当する領域で多数の実行役の間で統合的に使用できる様に、必要に応じて設定方法の選択肢に制限をかけます。
既存の標準に明確化や拡張が必要な場合には、関連する標準団体に提言します。
この先導的活動は異なる医療専門領域、地域で、多くの後援者や支援団体を持っています。
北 米 で の主 要 な後 援 者は 、 医 療情 報 管理 シ ステ ム 協 会 (Healthcare Information andManagement Systems Society, HIMSS)、北米放射線協会（Radiological Society of North
America, RSNA）です。IHE カナダが組織されています。IHE 欧州は、欧州放射線科協会(ERA)、欧州放射線医会議(ECR)、放射線科電気医療機器産業協働委員会(COCIR)、ドイツ
放射線学会(DRG)、ユーロ PACS 協会、病院情報システム近代化期成同盟(GMSIH)、フランス放射線学会(SFR)、イタリア医学放射線学会(SIRM)、欧州健康記録局(EuroRec)、を含む多数の団体の連合に支持されています。日本では、IHE-J は経済通商産業省(METI)、厚
生労働省、MEDISC-DC の後援をうけ、協力団体として、日本画像医療システム工業会(JIRA)、保健医療福祉情報システム工業会(JAHIS)、日本医学放射線学会(JRS)、日本放射線技術学会(JSRT)、日本医療情報学会(JAMI)があります。医療専門家を代表する他の団体
は専門と地域の協会を超えて、IHE の拡大に参加するよう招かれています。

1.1 テクニカルフレームワークの概観
本文書、すなわち、IHE IT 基盤テクニカルフレームワーク（ITI TF）は、最適な医療を支えるため、
適切な医療情報共有を振興し情報統合の目的を果たすべく、定められている標準規格の実装法を定義します。本文書は毎年拡張され、一般への公開期間と閲覧をへて、誤りの発見と訂正をおこない、常時維持管理されています。最新版は第 10 最終版で、2013 年 9 月に定義され実装された
IHE ト ラ ン ザ ク シ ョ ン を 記 述 す る も の で す 。 文 書 の 最 新 版 は 常 に http://www.ihe.net/Resources/Technical_Frameworks にて取得可能です。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

12

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________IHE IT 基盤テクニカルフレームワークは、医療機関の機能単位の構成要素である IHE アクタ（Actor、実行役）をさだめ、アクタ間の相互作用を標準規格準拠の連携したトランザクションのセットとして定めています。本文書はトランザクションの本体を常に深化させています。第１巻（ITI
TF-1）は IHE 機能の高所からの概観で、統合プロファイルと呼ばれる、機能単位として組織化されたトランザクション群を示して、特定の IT 基盤の要望を処理する能力を明らかにします。
IT 基盤テクニカルフレームワーク第 2a、2b, 2x 巻は IT 基盤統合プロファイルで使用される IHE
トランザクションの個々についての詳細な技術的な記述をのせます。第 3 巻は内容仕様と複数のトランザクションで使用される仕様を含みます。これらの巻には一貫性があり、他の IHE 領域の統合
プロファイルとあわせて使うことができます。
IHE 内の他の領域はそれぞれが関与する領域でテクニカルフレームワークを作成し、これらとあわせて、IHE テクニカルフレームワークを形成します。たとえば、以下のテクニカルフレームワークが使用可能な例です。


IHE IT 基盤テクニカルフレームワーク



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



IHE 検査テクニカルフレームワーク

IHE 患者ケア協働テクニカルフレームワーク



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

適応可能な場合には、他のテクニカルフレームワークが参照されます。テクニカルフレームワークを参照する場合の慣例は、ITI TF-1 の 1.6.3 節をご覧ください。

1.2 IT 基盤テクニカルフレームワーク第 1 巻の概観
第一節の残りの部分では、テクニカルフレームワークの一般的性質、目的と機能を記述します。第
二節ではテクニカルフレームワークを形成する IHE 統合プロファイルの構想を紹介します。
第三節以降では、統合プロファイルの詳細な説明が、処理目標となる IT 基盤課題とアクタ、それに含まれるトランザクションが、記述されます。
付録は、アクタやトランザクションのまとめの一覧、統合プロファイルに関連した特定の問題についての詳細や用語集、略語集です。

1.3 想定読者
本書が想定する読者は以下です。
・医療機関の IT 部門
・IHE に参加する企業の技術職員________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

13

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

・標準規格を定める専門家
・医療情報システム統合と業務流れに興味のある人

1.4 標準規格との関係
IHE テクニカルフレームワークは、散在する医療システムを構成する機能部品（IHE アクタ、実行役）を、もっぱら医療機関における情報連携の観点から、定義するものです。現状の整備状況では、
ATSM,DICOM, HL7, IETF, ISO, OASIS, W3C 規格に準拠した協働するトランザクションの集合です。IHE の主導する範囲が拡がるに連れ、他の標準規格によるトランザクションが必要に応じて含まれる様になります。
時に IHE はこれら標準規格に準拠して特別なオプションの選択肢を推奨します。しかし、IHE は標準に違反する様な技術選択肢を導入することはありません。もし、標準規格に誤りや拡張の必要性を発見したときは、標準を作成している団体にその団体の規格変更戦略の中で、解決を依頼するだけです。
IHE はそれ故、実装の枠組みであり、標準規格ではありません。IHE を標準規格と見るのは誤りです。製品が標準に適合するとの主張は、標準規格を直接に参照して行われるべきです。さらに、IHE 統合プロファイルの機能を実装した場合には、その能力を通知するため、IHE 統合宣言により、IHE テクニカルフレームワークへの適合性を明記できます。IHE 適合宣言を発する販売業者
はその内容について全責任を負います。異なった製品の IHE 適合宣言を比較することによって、
IHE の実行役と統合プロファイルの構想に習熟した使用者は、製品間の情報トランザクションがどの範囲まで可能かを知ることができます。IHE 適合性宣言の書式については ITI TF-1 付録 C を参照してください。

1.5 実製品との関係
IHE テクニカルフレームワークに記述された IHE 実行役とトランザクションは、実際の医療情報シ
ステム環境の抽象化です。トランザクションの一部は従来から特定種別の製品（たとえば、HIS、臨
床データ保管庫、放射線情報システム、臨床情報システム、あるいは、心臓病情報システム）により行われてきましたが、IHE テクニカルフレームワークは意図的に、機能や実行役と上記の製品種
別を関連つけないようにしています。IHE テクニカルフレームワークでは、個々のアクタには、シス
テムの統合に関連する機能のみを定義します。IHE 実行役の定義は、これを実装する機器の完全な仕様を規定するものと解釈してはなりません。同様に、医療機関の情報システムの構造を完全に記述したものと解釈してもなりません。
実行役とトランザクションを定義するのは、医療機関情報システム環境の機能的要素間のトランザ
クションを定義する基盤を提供するためです。一個の機器が多数の機能を有する場合には、製品________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

14

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________と外部機能とのインターフェースとのみが、IHE では有意とされます。したがって、すべての機能を一個にまとめた情報システムと、複数のシステムの集合体が協働して同一の目的に使えるシステムとの優劣を論じません。しかしながら、IHE テクニカルフレームワークを使用した複数の会社の製作になるシステムの統合を、IHE のデモでは強調しています。

1.6

凡例

テクニカルフレームワークの構想を提示するため、以下の凡例を使用し、IHE テクニカルフレーム
ワークが依拠する標準規格の適用法を明示します。
1.6.1 アクタとトランザクション図および表
個々の統合プロファイルはトランザクションにより相互に活動する実行役の一セットを提示したものです。実行役（actor）は情報システム、あるいは情報システム構成要素であって、医療施設の活動に必要な情報を、生成、管理、あるいは実行するものです。トランザクション（Transaction）は、標準規格に準拠した通信文により、必要とされる情報をアクタ間で相互に伝達することです。
以降に記述される実行役とトランザクションの図と表は、該当の統合プロファイルの個々の実行役が支えるべきトランザクションを示したものです。
図に示されるトランザクションはその名称と ITI TF-2a と 2b で定められた番号で示されます。トラン
ザクション番号は図では、角括弧で囲まれた、テクニカルフレームワークの領域を接頭語にもつ番号で示されます。
プロファイルが適切かつ有益に機能するには、事前に整備されたプロファイルに依存することがあります。たとえば、施設使用者認証(EUA）統合プロファイルは時刻一貫性（CT）に依存します。このような依存関係は、知りたい統合プロファイルを表 2-1 で見つけ、どのような統合プロファイルを前提的に必要とするかを知れば、わかります。 アクタは必要な統合プロファイルに適合すると同時に、依存するプロファイルにも適合しないとなりません。
1.6.2 処理流れ図
以下の統合プロファイルの説明には処理流れ図が含まれ、プロファイルが関連する実行役間のトランザクション順列を示しています。
この図は概観を示すもので、施設の業務流れ全体が見えるようにしています。IHE が規定しないト________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

15

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

ランザクションや活動は図中では斜体で示されており、関連する IHE トランザクションがより広範な
医療情報システムに適合するような追加の状況を示します。
この図は唯一の解決法を示すものではありません。実行役の別のまとめを作ることもでき、他のプロファイルから追加のトランザクションを混ぜ合わせることもできます。
トランザクションの順序に融通が利く場合もあります。融通が利く場合は、融通性を示す注釈が通常つけられます。トランザクションは、一義的な情報の流れに従う矢印で示され、必ずしも情報の発動者ではありません。
1.6.3 テクニカルフレームワークの相互参照
テクニカルフレームワークの同じ巻にある別の節への参照が行われるときには、節番号がそのまま使われます。別の巻、あるいは、別領域への参照が行われるときは以下の書式が使われます。
<領域識別子> TF-<巻番号>: <節番号>、
こ こで <領 域 識 別 子 >は 、IHE 領 域 の 短 い 名 称 で す （ ITI = IT infrastructure, RAD =Radiology）<巻番号>は任意のテクニカルフレームワークの適用される巻番号です（たとえば、1, 2a, 2b, 2x）<節番号>は適用される節番号です。
たとえば；ITI TF-1: 3.1 は、IHE ITI テクニカルフレームワークの第 1 巻、3.1 節を示します。
RAD TF-3: 4.3.3 は、IHE 放射線テクニカルフレームワークの第 3 巻、4.33 節を示します。
ITI TF-2x: Appendix A は、IHE ITI テクニカルフレームワークの第 2x 巻付録 A を示します。
テクニカルフレームワークのトランザクション番号への参照が行われるときには、以下の書式が使われます。
[<領域識別子>-<トランザクション番号>]<トランザクション番号>は特定された領域でのトランザクション番号です。
たとえば、[ITI-1]は、IHE ITI テクニカルフレームワークのトランザクション 1 を示します。

1.7 本年に導入された変更の範囲
IHE テクニカルフレームワークは毎年更新され、新しいプロファイル、訂正とこのプロファイルで使用する新しいトランザクションを反映します。
ITI テクニカルフレームワークのこの版は、以下の統合プロファイルを最終的に定めます。
1. 表示用情報取得（Retrieve Information for Display, RID）－診療の向上に備えるため必要な患者情報の単純で迅速な閲覧のみの利用。CAD, PDF, JPEG, などのよく知られた表示形式の、既存の永続的書類の利用を可能とします。これは、アレルギー、現在の________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

16

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

投薬、レポートのまとめ、のような特定の患者自身の重要情報の利用も医師に提示する
ため可能とします。
2. 施設使用者認証（Enterprise User Authentication, EUA） － この統合プロファイルに参加する全ての機器、ソフトウェアに対して、一使用者一名前を実現し、中央化された使用者認証管理を容易とし、一回の認証で済む利便性と迅速性を提供する手段。このプロファイルは Kerberos 認証（RFC 1510）と HL7 CCOW 標準に影響を与えます。
3. 患者識別相互参照（Patient Identifier Cross-referencing, PIX）－複数の患者識別圏からの患者識別の相互参照を与えます。これらの患者識別は患者識別消費役に使用され、別々の識別で知られている情報源から、一人の患者についての情報を関連つけます。小児基本情報オプションも含みます。
4. 患者同期下アプリケーション（Patient Synchronized Applications, PSA）－使用者のワークステーション上では独立し、結ばれていないアプリケーションを使用して一人の患者のデータをみる手段で、複数のアプリケーションの上で同じ患者を選ぶ作業を繰り返す
手間を大いに減らします。一人の患者が持つ複数の識別を解決するため、患者識別相
互参照プロファイルを使用すれば、異なる患者識別圏からのデータも閲覧できます。患者情報状況管理のため、このプロファイルは HL7 CCOW 標準に影響を与えます。
5. 時刻一貫性 （Consistent Time, CT）－複数の実行役やコンピュータの間で時刻を同期させる機構。種々の基盤、保安、取得プロファイルが、複数のコンピュータに一貫性のある
時間軸の使用を必要としています。時刻一貫性プロファイルでは時刻エラーの中央値は1 秒以下です。
6. 患者基本情報問合せ（Patient Demographic Query, PDQ）－使用者が指定した検索条件で、複数の散在するアプリケーションから患者情報サーバに問合せ、患者一覧表を得て、患者基本情報（オプションで来院情報や来院関連情報）をアプリケーションに直接取り込む方法を与えます。小児基本情報オプションも含みます。
7. 監査追跡と拠点認証（Audit Trail and Node Authentication, ATNA）－基本安全拠点（Basic Secure Node）の特性を確立します。すなわち:


拠点に前提的に必要な安全環境（使用者の特定、認証、権限付与、利用制限、など）を記述し、保管監視員が拠点の環境にこれらが合致するか否かを決められる様
にします。



拠点の基本的監査要求事項を定めます。



TLS あるいは同等の機能を用いる拠点の通信に対する基本的保安要求事項を定めます。



基本安全拠点と、監査情報を集積する監査記録保管拠点との間の監査通信文の交換の特性を確立します。



このプロファイルは特定の領域のテクニカルフレームワークが、特定領域のオプショ
ンとしてこのプロファイルを拡張できるように作られています。拡張は、追加の監査事________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

17

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

例報告の要求事項、特に実行役に特異な要求事項に対して、行われます。
8. 職員録（Personnel White Pages, PWP）－は職員の索引情報の利用を可能とします。この情報は、施設の臨床的、あるいは非臨床的なアプリケーションで広く使われます
9. 施設間文書共有（Cross-Enterprise Document Sharing , XDS）－1 つの XDS 連携圏（たとえば、療養コミュニティ）に属する医療提供施設が、診療活動を進める際に、臨床記
録を書類の形式で交換して、一人の患者の療養で協調することを可能とします。このプロファイルは ebXML Registr 標準規格と SOAP 規格に依拠しています。施設間文書共有が可能であるように、詳細に ebXML Resigtry の設定法を記述します。
10. 施設間使用者認証プロファイル（Cross-Enterprise User Assertion Profile, XUA）－認証
された主宰役の識別情報（使用者、アプリケーション、システム、など）の取得要求を、施設の境界を越えるとトランザクションで通信する手段を提供します。施設間通信の説明責任を果たすため、要求の受け手が利用の可否を決め適切な監査記録を生成する様な方法で、要求主体を識別する必要があります。XUA プロファイルは、独自の使用者認証方法を持ち独自で使用者名簿を持つ施設でも、使用者認証を第 3 者にゆだねる施設でも、使用可能です。
11. 患者管理（Patient Administration Management, PAM）－患者識別、登録、受診管理トラ
ンザクションを、施設内のみならず、施設間でも、提供します。
12. 施設間書類媒体交換（Cross-Enterprise Document Media Interchange, XDM）－通常のファイル形式と索引構造を持つ文書を、数種類の通常の媒体により、情報交換する方法を提供します。これにより、患者は医療情報を物理媒体で持ち運ぶことができます。媒体上の書類の伝達に、個人対個人の e-mail を使用することを許可します。
13. 基本患者プライバシー同意（Basic Patient Privacy Consents, BPPC）－患者のプライバシ
情報に関する同意を記録し、内容消費役が同意に適するように情報を使用する方法を提供します。このプロファイルは、XDS 連携圏が複数のプライバシ保護方針を作成する
方法を記述して XDS を補完し、XDS 実行役（たとえば、電子健康（EHR）システム）で使用可能な利用制限をいかに行うかを記述します。
14. 施設間スキャン書類共有（Cross Enterprise Sharing of Scanned Dcumants, XDS-SD）－書類源のシステムで管理されている患者の健康記録の統合性を維持するため、構造化された医療メタデータを、医療に特異的でない書類形式と関連付けるためのプロファイ
ル。
15. 施設間高信頼書類交換（Cross-Enterprise Document Reliable Interchange, XDR）－高信頼性の通信文システムを用いた書類交換法を提供します。XDS の様な種類共有のための基盤が存在しない状況で、EHR, PHR, その他の医療 IT システムとの間での直接的な書類の交換を可能とします。
16. 複数患者問合せ（Multi-Patient Queries）－臨床家や臨床施設の品質認証、臨床研
究データの収集、あるいは、公衆健康モニタの様な、データ分析に関連する領域で必要________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

18

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________とされるある種の条件にもとづいて、書類保管庫に集合的な問合せを行う方法を提供します。
17. 患者識別相互参照 HL7V3（Patient Identifier Cross-referencing HL7 V3, PIX V3）－
複数の患 者識別圏からの相互参照を提供します。これらの患者識別は、識別情報消費役により、それぞれ別の患者識別を持つ情報源から一人の患者についての情報のみを
関連付け ます。このプロファイルは HL7 V3 を通信文形式に用い、SOAP を基礎とする
インターネットサービスを伝送に使用します。
18. 患者基本情報問合せ HL7V3（Patient Demographics Query HL7 V3, PDQV3）－使用者が指定した検索条件に基づき、患者情報サーバに患者の一覧表を問合せ、患者基本情報を直接アプリケーションに取り込む方法を、分散して存在する複数のアプリケーションに提供します。このプロファイルは HL7 V3 を通信文形式に用い、SOAP を基礎とする
インターネットサービスを伝送に使用します。
19. 共同体間情報利用（Cross-Community Access, XCA）－他の医療圏が保有する患者に関連する医療データを問合せて取得する手段を使用可能とします。共同体は、確立された方法で臨床情報を共有するため、共通の運用方針を使用してともに活動することを合意した施設、機関の結合体です。
20. データ収集用紙取得（Retrieve Form for Data Capture, RFD）－医師・研究者と電子デー
タ取得システムまたは他のデータ収集官庁との間で、表形式データの収集と提出を行う
手段を提供します。
21. 値セット共有(SVS) – 値セット保管庫から値セットを取得する二つの機構を提供します。

1.8 保安面との関係
IHE トランザクションは、HIPAA や米国以外での同様な規制のごとく、個人情報保護の法律や規制に則り保護されねばならない情報をしばしば含みます。IHE には以下に示す 2，3 の保安とプラ
イバシに焦点を定めたプロファイルがあります。他の IHE プロファイルは通常、特別のプライバシ
保護策を持っていませんが、一個以上の安全プロファイルと適切に一括化されると期待しています。:


監査追跡拠点認証（ATNA）プロファイルはネットワーク内の拠点が認証されているのを確認する方法を特定しています。



ATNA プロファイルは安全、あるいはプライバシに関連する事象を報告する監査通信文を定めています。



施設使用者認証（EUA）プロファイルは、使用者を認証する方法と、認証された使用者の情報をアプリケーション間で共有する方法とを、特定します。



職員録(PWP)プロファイルは、システム使用者の識別情報を保有する保管庫を提供します。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

19

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

実装社は自製品の安全要求を満たすためこれらの IHE プロファイルを使うことができます。
施設は、各施設の要望を満たし規制要求事項を遵守するため、方針と業務流れを実装しなければなりません。

1.9 注釈IHE International はこの文書および IHE についての意見を歓迎します。意見は http://www.ihe.net/radiology/radiologycomments.cfm にあるコメント様式、あるいは、e-mail を IT
基盤領域委員会の委員長や秘書に、iti@ihe.net 宛にお寄せ下さい。

1.10 著作権許諾
Health Level Seven, Inc は IHE に HL7 規格の表を複製する許可をあたえています。この文書
中の HL7 の表の著作権は Health Level Seven, Inc. にあります。
HL7 から材料を引用するときには、明示されます。

1.11 IHE テクニカルフレームワークの開発、維持手順
IHE IT 基盤技術委員会は、IHE IT テクニカルフレームワークを継続的に維持し、一年周期で拡張を行っています。製造者と使用者の双方が IHE 準拠製品の仕様策定、開発、購入に際し依拠できるよう、仕様の安定確保を目指して、枠組みの開発と維持を原則に基づいて行います。
原則の第一は、テクニカルフレームワークのいかなる拡張、明確化、訂正も、従前の版との後方適合性を維持しなければならないということです。これは、従前の版に定めらた IHE 実行役と統合プ
ロファイルを実装したシステムとの相互運用性を保つためです。
IHE テクニカルフレームワークの安定性を確保するため、改訂は定期的に一年周期（図 1.10-1）
で以下の 3 段階で行われ、再公表されます。
1. IHE IT 基盤技術委員会は、テクニカルフレームワークの現行安定版をへの追補を作成し、IHE 戦略計画委員会が特定した新しい機能を加え、パブリックコメント
用に公表します。
2. パブリックコメント期間に受け付けたすべてのコメントは処理され、テクニカ
ルフレームワークは更新され、新しい版は試験実装版（Trial
implementation）として公表されます。この版はテクニカルフレームワ
ークの安定版と新しく作成された追補からなります。これが例年の IT 基________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

20

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

盤コネクタソン用に各社が試験実装に使用する版です。
3. 委員会はテクニカルフレームワークの試験実装版への変更提案を定期的に考慮しますが、これには、コネクタソンに参加する実装社からの提案も含まれます。コネクタソンの 60 日以内に受け受けたすべての提案が解決した
ら、テクニカルフレームワークの版は最終版（Final Text）として公表されます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

21

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

2. IT 基盤統合プロファイル
IHE IT 基盤プロファイル（図 2-1）は医療機関の統合要望や情報システムの統合能力を正確に討議するとき、医療専門家と販売会社が使用できる共通の言語となります。 統合プロファイルは、特定された臨床的要望に応える様に設計された標準規格の実装を、特定します。IHE ITI テクニカ
ルフレームワークの詳細な仕様を参照することにより、機器使用者と販売社がどの IHE 機能を必要とするか、提供できるか、を述べられる様になります。
統合プロファイルは IHE 実行役とトランザクションとで記述されます。実行役（ITI TF-1: 付録 A 参照）は、施設での臨床あるいは運用活動に関連する情報を生成、管理、働きかける情報システムまたは情報システムの構成要素のことです。トランザクション（ITI TF-1: 付録 B 参照）は、標準に準拠した通信文により必要な情報を交信する実行役間の相互作用です。
販売社の製品は適切な実行役とトランザクションを実装して統合プロファイルを使用可能とします。
任意の一個の製品は一個以上の実行役と一個以上の統合プロファイルを実装しています。

図 2-1 IHE IT 基盤統合プロファイル

2.1 統合プロファイル間の依存関係
1 つの統合プロファイルの実装に、他の統合プロファイルに定義された機能が前提的に必要な場合に、依存が有ると言います。図 2-1 に、IHE IT 基盤統合プロファイルの依存を示します。図中の矢印は、任意の統合プロファイルからそれが依存するプロファイルの方向に________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

22

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

引かれます。表 2-1 はこれを表で示したものです。
いくつかの依存では、1 つのプロファイルに必要な実行役が、他の統合プロファイルに必要な１個以上の実行役と一括化されることがあります。たとえば、施設使用者認証（EUA）
は、他の参加実行役が時刻一貫性（CT）プロファイルと一括化されるよう要求します。EUA
実行役は適切に機能するには、CT 実行役を参照せねばならないからです。
表 2-1: 統合プロファイルの依存関係________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

23

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

依存するプロファイルを使用可能とするには、前提的に必要なプロファイルに必要なトラ
ンザクションに加え、依存するプロファイルに必要なトランザクションも使用可能とせねばなりません。時には、実行役がプロファイルの組のいずれかを選択することが前提的に必須となります。

2.2 統合プロファイルの概観
この文書では、個々の統合プロファイルは、以下により定義されます。


使われる IHE 実行役________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

24

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________



個々の IHE 実行役が交換する IHE トランザクションの特定の組合わせ

これらの要求事項は統合プロファイルで使用可能な個々の実行役に必要なトランザクショ
ンの表として提示されます。複数の統合プロファイルで使用可能な実行役は、使用可能な
プロファイルのそれぞれに必要なすべてのトランザクションを使用可能とせねばなりません。
IHE 統合プロファイルは標準規格への適合宣言ではなく、IHE は認証機関でないことに注意してください。使用者は販売社に、HL7 や DICOM のような標準規格制定団体が発行する標準への適合宣言を提供するよう要求してください。標準への適合は、IHE 統合プロフ
ァイルを適用する販売社の必要条件です。
IHE では処理できない、情報システム統合に欠かせない重要な要求事項があることに注意
してください。統合を成功させるには、破綻を回避する計画、失敗しても安全が保たれる
戦略、特定され相互に理解されている機器の実行能力、きちんと定義されたユーザインタ
ーフェース、明確にされたシステムの制約、詳細な費用目標、維持と保守の計画が必要です。
2.2.1 本節は予約済み
2.2.2 本節は予約済み
2.2.3 表示用情報取得（Retrieve Information for Display, RID）
表示用情報取得は、診療の向上のために、単純で迅速な患者情報の利用を可能とします。
CDA, PDF, JPEG などの良く知られたファイル形式の永続性書類（訳者注: 長期に渡り変更されないで保存されるデータのこと）の利用を可能とします。アレルギー、現在の服薬、報告書の要約などの、特別な患者中心の重要情報を、臨床家に提示するために、利用可能とします。他の二つの IHE 統合プロファイル－施設使用者認証（EUA）と患者識別相互参照（PIX）－を結合する事により、この統合プロファイルの限界を医療機関内の組織を越えて広げます。この IHE 統合プロファイルは HTTP, インターネットサービス（web services）、
IT 表示書式、HL7 CDA Level 1 に影響します。
2.2.4 施設使用者認証（Enterprise User Authentication, EUA）
施設使用者認証（Enterprise User Authentication）はこの統合プロファイルに参加する全ての機器、ソフトウェアに対して、一使用者一名前を実現する方法を定めます。この統合プロファイルは中央化された使用者認証管理を容易とし、一回の認証で済む利便性と迅速性を使用者に提供し________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

25

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________ます。このプロファイルは Kerberos 認証（RFC 1510）と HL7 CCOW 標準に影響を与えます。
2.2.5 患者識別相互参照（Patient Identifier Cross-referencing, PIX）
患者識別相互参照（Patient Identifier Cross-referencing）は複数の患者識別圏からの患者識別の相互参照を可能とします。これらの相互参照された患者識別は「患者識別消費役」に使用され、別々の識別で「知られている」情報源から、一人の患者についての情報を関連つけます。これにより、臨床家は患者のより完全な情報を見ることができます。
2.2.6 患者同期下アプリケーション（Patient Synchronized Applications, PSA）
患者同期下アプリケーション（Patient Synchronized Applications）は使用者の一個のワークス
テーション上で、そのままでは独立していて連結されていないアプリケーションの間で、一人の患者のデータを閲覧できる様にします。複数のアプリケーションの上で同じ患者を選ぶ作業を繰り返す
手間を大いに減らします。同時に間違った患者のデータを閲覧することから生じる医療過誤の可能性を減らします。患者識別相互参照（PIX）プロファイルと共用できる能力を使用すれば、臨床家と IT スタッフに境界のない作業環境を与えます。特に患者情報状況管理のため、このプロファイル
は HL7 CCOW 標準に影響を与えます。
2.2.7 時刻一貫性 （Consistent Time, CT）
時刻一貫性 （Consistent Time）は複数の実行役やコンピュータの間で時刻を同期さ せ る 機 構を定義します。種々の基盤、安全、取得プロファイルには、複数のコンピュータの間で一貫性のある時間軸の使用が必要です。時刻一貫性プロファイルでは時刻エラーの中央値は 1 秒以下です。
設置オプションではもっと正確な同期が行えます。時刻一貫性プロファイルは、RFC 1305 で定義された NTP（Network Time Protocol）の使用法を定めます。
2.2.8 患者基本情報問合せ（Patient Demographics Query, PDQ）
患者基本情報問合せ（Patient Demographics Query）は使用者が指定した検索条件で、複数の散在するアプリケーションから１個の患者情報サーバに問合せ、患者一覧表を得て、患者基本情報（オプションで来院情報や来院関連情報）をアプリケーションに直接取り込む方法を与えます。
2.2.9 監査追跡と拠点認証（Audit Trail and Node Authentication, ATNA）
追跡と拠点認証（Audit Trail and Node Authentication）は、基本安全拠点（Basic SecureNode）の特性を確立します。すなわち、
1. 拠点に前提的に必要な安全環境（使用者の特定、認証、権限付与、利用制限、など）を記述し、保安監視員が拠点の環境にこれらが合致するか否かを決められる様にします。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

26

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

2. 拠点の基本的監査要求事項を定めます。
3. TLS あるいは同等の機能を用いる拠点の、通信に対する基本的安全要求事項を定めます。
4. 基本安全拠点と、監査情報を集積する監査記録保管拠点との間の監査通信文の交換の特性を確立します。
5. 安全拠点の要求事項の全てを満たすことのできない製品の設定法を記述する、安全
アプリケーション実行役（Secure Application actor）を定義します。
注: ATNA の保安考慮には安全拠点の使用が必須です。安全アプリケーションは安全拠点環境に容易に統合できる様にする製品設定が可能であること、と定義されます。これは、アプリケーションの機能に直接関連する、全ての保安関連機能を行うことができるからです。

このプロファイルは特定の領域のテクニカルフレームワークが、特定領域のオプションとしてこのプ
ロファイルを拡張できるように作られています。拡張は、追加の監査事例報告の要求事項、特に実行役に特異な要求事項に対して、行われます。放射線テクニカルフレームワークの放射線監査追跡オプションはこの一例です。
2.2.10 施設間書類共有（Cross-Enterprise Document Sharing, XDS）
施設間書類共有（Cross-Enterprise Document Sharing, XDS）は、1 つの XDS 連携圏（たとえば、療養コミュニティ）に属する医療提供施設が、診療活動を進める際に、臨床記録を書類の形式で交換して、一人の患者の療養で協調することを可能とします。国の書類保管庫と書類登録所は、
任意の XDS 連携圏内の患者についての情報の縦断的記録を生成します。このプロファイルは
ebXML Registry 標準規格と SOAP 規格に依拠しています。このプロファイルは施設間文書共有が可能であるように、詳細に ebXML Registry の設定法を記述します
2.2.11 職員録（Personnel White Pages, PWP）
職員録（Personnel White Pages）は職員の索引情報の利用を可能とします。この情報は、施設の臨床的、あるいは非臨床的なアプリケーションで広く使われます。この情報は臨床業務流れを補強する（連絡先情報）ため、ユーザインターフェースを強化する（使用者に優しい名称や標題）、同一性判定の強化（デジタル証明書）に使用できます。この職員録は以前 IHE で定義された施設使用者認証（EUA）統合プロファアイルと関連付けられます。
2.2.12 この節は、書類可用性通知（Notification of Document Availability, NAV）に予約済
2.2.13 施設間使用者認証プロファイル（Cross-Enterprise User Assertion, XUA）
施設間使用者認証（Cross Enterprise User Assertion）は認証された主体（使用者、アプリケー
ション、システム、など）識別情報の取得要求を、施設の境界を越えるトランザクションで通信する手________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

27

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

段を提供します。施設間トランザクションの説明責任を果たすため、要求の受け手が利用の可否を決め適切な監査記録を生成する様な方法で、要求主体を識別する必要があります。XUA プロファ
イルは、独自の使用者認証方法を持ち独自で使用者名簿を持つ施設でも、使用者認証を第 3 者にゆだねる施設でも、使用可能です。
2.2.14 患者管理（Patient Administration Management, PAM）
患者管理（Patient Administration Management）は、患者情報、および、関連する人物（介護者、保証人、隣人、など）の様な追加の情報の連続性と統合性を維持します。患者の来院情報と居所に着いての最新の情報を提供せねばならないシステムの間での情報交換を調整します。このプ
ロファイルは、通院および急性疾患診療での使用を可能とし、患者識別送付、入院と退院、転院と来院管理、同様に、明示的で正確なエラー通知とアプリケーションの通知を含みます。
PAM は２つの想定業務を支えます: 一施設に一つの中央化された患者登録システムを施設全体で使うか、一施設に複数の患者登録システムを持ち、異なった臨床状況に応じて協働して使用するか、です。
2.2.15 施設間高信頼書類交換（Cross-Enterprise Document Reliable Interchange, XDR）
施設間高信頼書類交換（Cross-Enterprise Document Reliable Interchange）は高信頼性の通信文システムを用いた書類交換法を提供します。XDS 登録所や保管庫の様な書類共有のための基盤が存在しない状況で、EHR, PHR, その他の医療 IT システムとの間での直接的な書類の交換を可能とします。
2.2.16 施設間書類媒体交換（Cross-Enterprise Document Media Interchange, XDM）
施設間書類媒体交換（Cross-Enterprise Document Media Interchange）は、通常のファイル
形式と索引構造を持つ文書を、数種類の通常の媒体により、情報交換する方法を提供します。こ
れにより、患者は医療情報を物理媒体で持ち運ぶことができます。医療書類の伝達に、個人対個
人の e-mail を使用することを許可します。
2.2.17 データ収集用紙取得（Retrieve Form for Data Capture, RFD）
データ収集用紙取得表（Retrieve Form for Data Capture）は、外部システムの要求事項に適合する様に、使用者が使用中のアプリケーションの中でデータを収集する方法を提供します。
RFD は書式源から用紙を取得し、用紙を完成し、事例のデータを表示アプリケーションから元のア
プリケーションへ返信できる様にします。
2.2.l8 共同体間情報利用（Cross-Community Access, XCA）
共同体間情報利用（Cross-Community Access）は、他の共同体が保有する、患者に関連する医________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

28

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

療データを問合せ、取得する手段を使用可能とします。共同体は、確立された方法で臨床情報を共有するため、共通の運用方針を使用してともに活動することを合意した施設、機関の結合体です。施設や機関は、HER や PHR などの、どのようなタイプの医療アプリケーションも主宰できます。
共同体は、世界的に一意の、homeCommunityId と言われる識別子で同定可能です。一つの共同体に属する医療機関は、他の共同体の一員となることもできます。この様な共同体は、内部の共有構造がどうあろうとも、XDS プロファイルを用いて書類を共有する XDS 医療圏でも、その他の共同体でも良いです。
2.2.19 基本患者プライバシ同意（Basic Patient Privacy Consents, BPPC）
基本患者プライバシ同意（Basic Patient Privacy Consents）は、患者のプライバシ情報に関する同意を記録し、内容消費役が同意に適するように情報を使用する方法を提供します。このプロファ
イルは、XDS 連携圏が複数のプライバシ保護方針を作成し実装する方法を記述し XDS を補完し、XDS 実行役（たとえば、電子健康（EHR）システム）で使用可能な利用制限をいかに行うかを記述します。
2.2.20 スキャン書類共有（Cross Enterprise Sharing of Scanned Documents, XDS-SD）
種々の伝統的書類、フィルム、電子的およびスキャン出力形式が、保存と臨床文書交換に使用されます。この様な書類形式は診療記録用に設計されておらず、さらに、書類に関連するメタデータ、
たとえば、患者識別、基本情報、受診記録、指示情報や処置情報、を保存する標準的方法もありません。患者の健康記録の統合性を維持するためには、情報源システムで管理される際には、この様な書類を構造化された診療情報メタデータと関連付けることが重要です。書類共有（Cross
Enterprise Sharing of Scanned Documents）は、書類源の医療メタデータを書類とともに保存できる方法を提供する必要があります。
2.2.21 この節は予約済です
将来
2.2.22 この節は予約済です
将来
2.2.23 患者識別相互参照（Patient Identifier Cross-referencing HL7 V3, PIX V3）
このプロファイルは 2.2.3 節に記述された PIX プロファイルの機能と同じです。違いは、通信文の形式と、SOAP に基盤を置くインターネットサービスを使用することです。この変更により、施設間でデータ利用と交換に既存の IT 基盤を使用するのによく適したものになりました。PIX V3 プロファイ
ルは、複数の患者識別圏からの患者識別の相互参照を可能とします。これらの患者識別は、識別「情報消費役」により、それぞれ別の患者識別で「知られている」情報源から一人の患者について________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

29

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________の情報のみを関連付けるのに使われます。これにより臨床家が患者情報をより完全に閲覧できます。
2.2.24 患者基本情報問合せ（Patient Demographics Query HL7 V3, PDQV3）
このプロファイルの機能は 2.2.6 節で記述した PDQ と同じです。違いは、通信文の形式と、SOAPに基盤を置くインターネットサービスを使用することです。この変更により、施設間でデータ利用と交換に既存の IT 基盤を使用するのによく適したものになりました。分散して存在する複数の団体
あるいはアプリケーションに、使用者が指定した検索条件に基づき、患者情報サーバに患者の一覧表を問合せ、患者基本情報を直接アプリケーションに取り込む方法を提供します。
2.2.25 複数患者問合せ（Multi-Patient Queries, MPQ）
複数患者問合せ（Multi-Patient Queries）は臨床家や臨床施設の品質認証、臨床研究データの収集、あるいは、公衆健康モニタの様な、データ分析に関連する領域で必要とされる、ある種の条件にもとづいて、書類保管庫に集合的な問合せを行う方法を提供します。

2.3 製品への実装

Product Implementations

開発者には IHE 実行役（アクタ）とトランザクションを製品に実装するいくつかのオプションがあります。選択の決断には 3 つの水準のオプションがあります:

システムにどの実行役（アクタ）を使用するか（一個のシステムに複数の実行役（アクタ）が使えます）決めます。



個々の実行役（アクタ）について、どの統合プロファイルに使うかを決めます。



個々の実行役（アクタ）とプロファイルについて、どのオプションを使用するか決めます。

使用可能にしたい統合プロファイルには、全ての必須のトランザクションを実装しなければなりません（ITI TF-2a と ITI TF-2b を参照）。
実装する会社は、任意の製品について、使用する実行役（アクタ）、統合プロファイル、オプションが記された記述を提供しなければなりません。推奨する書式は ITI-TF-1 付録 C にあります。
一般に、製品にはいずれか一個の実行役（アクタ）、あるいは、実行役（アクタ）の組み合わせが使用されます。二個以上の実行役が一括されたとき、製品の機能を支える必要な情報の流れが可能であれば、実行役間の内部交信は十分と見なされます。たとえば、必要な患者識別の対応付け情報を患者識別相互参照管理役から取得するため、状況管理役は患者識別相互参照消費役を使用します。この様な内部交信の正確な機構は IHE テクニカルフレームワークの範囲外です。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

30

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

複数の実行役が一個の製品に一括されて実装される場合、製品が使用可能とするそれぞれの実
行役から始まる、あるいは、終わる全てのトランザクションが、使用可能でなければなりません（すなわち、IHE トランザクションは、製品の外部にインターフェースを与えられねばなりません）。
以下の例は、典型的なシステムにどのような実行役が期待されるかを記します。これは、要求事項を意図したものでなく、具体例を示したものです。
検 査室情 報 システムや放射 線ＰＡ ＣＳ システムの様な部 門システム は、情 報源 実行役 や 、
Kerberos 化サーバ実行役を含むことがあります。
臨床保管庫は、情報源実行役や、Kerberos 化サーバ実行役、および、患者識別相互参照消費役を含むことがあります。

3 表示用情報取得（Retrieve Information for Display, RID）
表示用情報取得（RID）は、使用者の現在のアプリケーション外の場所にあるが、よりよい診療のため、患者に焦点のある臨床情報を利用する（たとえば、放射線科から検査レポー
トを利用）単純で閲覧のみの利用を提供します。CDA 第一水準、PDF、JPEG などの様なよく知られた提示形式を持つ既存の永続書類の利用を可能とします。アレルギーや現在の投薬、報告書の要約の様な重要な患者に焦点のある情報を臨床家に提示することを可能にします。使用者の表示画面内の作業領域やアプリケーションの中からの利用により業務流れを補完します。
このプロファイルでは、医療に特異の情報意味を、この IHE プロファイルで呼ぶところの「提示」様式に変更する責任は、もっぱら情報源実行役のみにあります。その結果、表示
実行役はこの「提示」様式を、医療情報の意味論の一般的知識により、処理し見読化します。異なる様式は、(1)サーバによる制限事項、(2) 依頼側の表示装置がその制限（たとえば、
汎用 CDA 第一水準データ表）の中で見読化する際の表示柔軟性、により独自の特性を持ちます。
表示用に返信された情報とその臨床的正確性は情報源実行役が全面的に責任を負います。
この統合プロファイルは、情報源実行役が返信する書類の構造と内容を処理する産業標準に影響を与える能力を与えます。このプロファイルが HL7 臨床書類構造（CDA）を参照す
る場では、承認された CDA 第一水準のみに限定します。さらに、このプロファイルは、表示用に使用可能とするのを容易にする、CDA 第一水準の一部しか使用しません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

31

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________IHE IT 基盤テクニカルフレームワークの将来の拡張は、CDA 第二版と他の産業界標準によりいっそう影響を与え、SNOMED や臨床 LOINC の様な語彙、同様に臨床雛形も、組み込むようになります。
この統合プロファイルは利用制限や情報伝送中の保安については特に何も要求しません。
この手段は、施設使用者認証（EUA）[ITI TF-1: 4 参照]の様な、適切な保安関連の統合プ
ロファイルを通して実装されねばなりません。ITI TF-4: 付録 E に、施設使用者認証（EUA）と患者識別相互参照統合プロファイルと関連つけて、表示用情報表示（RID）統合プロファ
イルを使用する処理流れを記述します。

3.1 実行役・トランザクション
図 3-1 に、表示用情報取得（RID）に直接含まれる実行役と、その実行役間の関連するトラ
ンザクションを示します。施設使用者認証（EUA）（訳注: 原本では、”Enterprise"が抜けている）と患者識別相互参照（PIX）に参加しているため間接的に含まれる他の実行役は記述されていません

図 3-1: 表示用情報取得の実行役図
表 3-1 に、表示用情報取得（RID）に直接含まれる実行役のそれぞれに対するトランザクシ
ョンを示します。この統合プロファイルが使用可能と主張するには、実装機器は必須のトランザクション（"R"表記）を実行できねばなりません。この統合プロファイルに定められ、実装製品が選択可能なオプションの完全な一覧表は ITI TF-1: 3.2 にあります。
表 3.1-1:

表示用情報取得統合プロファイル－実行役とトランザクション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

32

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

トランザクション[ITI-11]は、以下のオプションの１つを情報源実行役が選択したときには、必須です。

トランザクション[ITI-12]は、永続文書オプション（Persistent Document Option）を情報
源実行役が選択したときには、必須です。
これは、表示実行役がトランザクション[ITI-11]により書類を取得するために固有識別（unique identifieres）を取得するときには、トランザクション[ITI-12]によるか、RID 統
合プロファイルの外にある他の手段によるか、であることを意味します。

3.2 表示用情報取得（RID）統合プロファイルのオプション
この統合プロファイルに選択可能なオプションは、表 3.2-1 に、適用される実行役とともに示されます。
表 3.2-1: 表示用情報取得統合プロファイル－実行役とオプション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

33

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

注 1: 薬剤一覧（List of Medications)は現在投与されている薬品の一覧を含みます。
処方要約とは異なります。後者は処方された薬であり、必ずしも今も投与されているわけでは有りません。
注 2:

上記のすべてのオプションで、”報告書要約”とは、一般的患者状況（患者氏名、など）

が、内容項目（エントリ）一覧とともに提供され、内容項目には、日付、専門、使用者が内容項目を選択できる様な他の情報の様な重要属性が含まれているものです。内容項目は、RID の永続 書 類 や、 他 のア プ リケ ーシ ョ ン が定 め た RID 要 約 を 参 照 する こ とが で きま す。 こ の一般的指針を越えて、特定の内容は使用状況や使用者の要望により影響されます。このような要約は、患者診療の中で更新され得るので、永続書類では有りません。

3.3 表示用情報取得の処理流れ

この節は、情報源から表示可能な患者情報が取得されたときの処理と情報の流れを記述します。３つの場合が区別されます。
第 1 例－表示用特定情報取得: 第一の例は実行役とその操作者が、患者に関連するある種の情報を、要求した場合の使用例です。特定の患者 ID についてある程度特定された情報取得
要望（たとえば、検査レポートの要約を取得する、など）が情報源に向けて発行されます。
患者 ID は発行元によって完全に保証され、不明な点が無いものとされます。発行された要望の種類によっては、追加の絞り込み条件が使われることがあります（たとえば、最新の N
個のレポート、値の範囲、など）。情報源実行役は、実行役自身が要望に関連があるとする、表示の準備が完了下情報を返信します。この統合プロファイルは、返信する情報内容の組織化と提示について、情報源実行役に全面的な柔軟性を与えています。情報源実行役は、
答えられない型の要望であるか、要望された患者 ID に該当する記録を有していないときは、
エラーメッセージで応答せねばなりません。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

34

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 3.3-1: 第一例: 表示用情報取得の処理流れ
第 2 例－書類取得: 第二の例は実行役とその操作者が、レポート、画像、ECG 記録の様な、１個に特定された書類を要望する場合の使用例です。情報源実行役は管理する、表示のみの内容物を提供するべく、提案された形式の１つを使用して要求に応えます。表示の詳細や書類内容の臨床的整合性は、情報源実行役の管理下にあります。画像表示役は、単に、要望を出した使用者に提示の準備が整った書類を表示するのみです。情報源実行役は、要望された書類が無い場合や、画像表示役が使用できる形式のどれもが、要望された書類の提示に適していないときは、エラーメッセージで応答せねばなりません。
注: この統合プロファイルは患者モニタに使用される様な、高度に更新が行われる情報への使用は意図していません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

35

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 3.3-2 : 第二例: 表示用情報取得の処理流れ
第 3 例－特定情報取得と複数書類取得処理流れ: 第三の例は、上記二つの例の組み合わせで、

特定情報取得（Retrieve Specific Information）と表示用書類取得（Retrieve Document for
Display）両トランザクションを順番に関連させる機能です。これにより永続書類へのリンクを、返信される特定情報のなかに入れたり、永続書類の中で他の永続書類への参照を入れたりできるようになります。たとえば、使用者は最近の退院報告書を要求して、返信された最近の退院レポートの要約一覧のなかから、特定書類を選びます。すなわち、使用者に表示された退院報告書から特定の手術報告書を選びます。手術レポートが取得され表示されます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

36

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 3.3-3 : 第三例: 表示用要約情報取得と複数書類取得情の処理流れ
同一の表示役が、順次異なったトランザクションを発行する事により同一の表示役が、１個以上の情報源実行役を巻き込むことがあります。この統合プロファイルは、表示役が１個以上の遠隔の情報源実行役に、表示用情報取得の要求が発行される様なアプリケーショ
ン環境に適合した、取得トランザクションの型・要望の型・特定キーとともに、つながる様に設定されていることを前提としています。将来の統合プロファイルはこのような施設に特有の設定業務を容易にする可能性があります。

4. 施設使用者認証（Enterprise User Authentication,

EUA）

施設使用者認証（EUA）－このプロファイルは本統合プロファイルに参加するすべての機器やソフトウェアで使用可能な、一使用者一氏名を確立する手段を定めます。これは、中央化した使用者認証管理を容易にし、使用者に”一回サイン後入場”（single sign-on）の利便性と迅速性を与えます。このプロファイルは Keroberos 認証（RFC 1510）と HL7 CCOW
標準規格（使用者サブジェクト）とに影響します。使用者認証は多くのアプリケーション
やデータ利用操作で必要で、このプロファイルは使用者には、業務流れ改善策となります。
IHE EUA プロファイルは、使用者と CCOW 使用者サブジェクト接頭語を定めて、使用者________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

37

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________向 CCOW 標準仕様の価値を高めます。このプロファイルは、監査追跡、利用制限、認証管
理、PKI の様な保安関連の処理を行いません。将来の統合プロファイルは EUA の補完とする形でこれらの補完関連事項が処理されます。
１個の施設で、１個の保安基本方針で管理され、共通のネットワーク圏を持つ環境を前提としています。保安のない、特に、インターネット利用は、興味深いですがこのプロファ
イルの範囲外です。遠隔医療や患者の医療記録データ利用についての考察もまた、範囲外です。ITI TF : 付録 G を参照してください。
拠点と機器の認証は IHE 放射線テクニカルフレームワークに記述された基本保安プロファ
イルに定められており、このプロファイルの一部では有りません。

4.1 実行役・トランザクション
このプロファイルで使用されるトランザクションの多くは RFC 1510 として規定された
Keroberos v5 標準に準拠します。この標準は 1993 年以来安定で、多くの基本ソフトウェ
ア（オペレーティングシステム）に実装され、10 年間の歴史上での攻撃に耐えてきました。
たとえば、Sun Solaris, Linux, HPUX, IBM-z/OS, IBM-OS400, Novell, MAc OS X,
Microsoft Windows 2000/XP のすべてが、相互操作可能な状態で実装されています。これは完全な一覧ではなく、他の多くの販売者が Kroberos を使用可能としています。
このプロファイルを越える追加の Keroberos の詳細については以下を推奨します。
RFC 1510 - http: //www.ietf.org/rfc/rfc1510.txt



MIT Jeroberos ホームページ - http: //web.mit.edu/keroberos/www/Keroberos のモートン案内書 - http: //www.isi.edu/~brian/security/kerberos.html



マイクロソフト Keroberos 情報 - http://www.mirosoft.com/TechNet/prodtechnol/windows2000ser/deploy/keroberos.asp

Keroberos の実装は世界中で広く手に入ります。いくつかの国では使用制限の法律がある暗号化も含んでいます。米国の輸出規制は、http: //www/bxa/doc/gov/Encryption で探せます。
図 4.1-1 は、施設使用者認証（EUA）に直接含まれる実行役と、その実行役間の関連するトランザクションを示します。”Other IHE Actor”と記された四角は、このプロファイル
内の実行役の近傍に一括される他の統合プロファイル由来の実行役です。認証の使用など
により間接的に含まれる他の実行役は記述されていません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

38

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 4.1-1: 施設使用者認証実行役の図
表 4.1-1 に、施設使用者認証（EUA）に直接含まれる実行役のそれぞれに対するトランザ
クションを示します。この統合プロファイルが使用可能と主張するには、実装機器は必須のトランザクション（"R"表記）を実行できねばなりません。"O"表記のトランザクション
はオプションです。この統合プロファイルに定められ、実装製品が選択可能なオプションの完全な一覧表は ITI TF-1: 4.2 にあります。
表 4.1-1: 施設使用者認証－実行役とトランザクション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

39

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

注 1: 使用者状況認証オプション（Authentication for User Context Option）が使用可能な時
は、トランザクションは必須です

CCOW は EUA 認証使用者の識別の共有を容易にしますが、使用者の認証はしません。状
況管理役と使用者状況参加者が、EUA 統合プロファイルに参加するには、依頼者認証代理役（Client Authentication Agent）が使用者認証オプション(Authentication for User
Option)を使用可能とする必要があります。この構成により使用者状況参加者に一貫性のある、施設全体に渡る使用者識別を提供しますが、Keroberos 信任状の利用法は定めていません。将来の IHE プロファイルはこの限界を処理する可能性があります。PSA と EUA の両方を使用するときは、依頼者認証代理役（Client Authentication Agent）が鍵を握る実行役であることに注意してください。ITI TF-1: 4.3.2 に概要を記した使用例を参照してください。依頼者認証代理役（Client Authentication Agent）と使用者状況参加者（User Context
Participant）の両方を実装するアプリケーションは、両方を使用不可値する設定ができねばなりません。
使用者一人のいかなる状況でも、一人の使用者には二つ以上の依頼者認証代理役（Client
Authentication Agent）が存在してはなりません。

4.2 施設使用者認証統合プロファイルのオプション
この統合プロファイルに選択可能なオプションを表 4.2-1 に、適用される実行役ととともに、示します。
表 4.2-1: 施設使用者認証―事項役とオプション

4.3 施設使用者認証プロファイル処理
4.3.1 基本使用者認証処理ながれ
施設使用者認証の使用で生じる一連の事象を、以下の図に示します。
図 4.3.1-1: 施設使用者認証プロファイルの基本的処理流れ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

40

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

施設使用者認証の使用で生じる一連の事象は:

使用者はセッションを開始します。これにより、使用者名・パスワード認証が開始され、Keroberos が使用する申し込み・応答システムに変換され、ネットワークにパスワードが伝わるのを防ぎます。この情報は切符許可切符（Ticket Granting Ticket, TGT）を取得する使用者認証取得トランザクショ
ンの一部として使用されます。



TGT は依頼者認証代理役により保存され内部で管理されます。TGT は使用者が認証されていることを示す証明書として働きます。

Keroberos 化されたそれぞれのサービスについて、依頼者認証代理役はサービ
ス切符取得トランザクションを使用してサービス切符を取得します。サービ
ス切符は Keroberos 化通信トランザクションの一部として使用されます。

Keroberos 化通信は、Keroberos データ交換で、HL7 や DICOM の様な、他の通信プロト
コルに統合されたものを言います。HL7 や DICOM は他の IHE トランザクションでも使用されています。Keroberos 化の詳細は種々で、Keroberos 化されたプロトコルについては別途記述されます。Keroberos 化により他のトランザクションに含まれる別の IHE 実行役が、認証された使用者の識別を、使用者認証や監査通信文の様な目的で、使用できる様にします。
依頼者認証代理役は、TGT やサービス切符の様な信任状の内部キャシュを保持します。切符の失効に応じて切符を更新し、有効期間内であれば切符の再使用を行い、セッションを________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

41

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

終わるときには、キャッシュから信任状を削除します。依頼者認証代理役は、Keroberos
信任状を、現場の基本 OS 機構の使用により、利用可能とせねばなりません。Kerobero 信
任状を必要とする他の IHE 実行役は現場の基本 OS 機構の使用により、信任状を得るよう、
強く奨励されています。切符管理の OS サポートは多種類の OS に実装され、定められています。
4.3.2 使用者認証と使用者同期アプリケーション処理流れ
この例では、他のアプリケーションと同じデスクトップで使用者認証が使用可能なアプリ
ケーションが、同じ使用者識別と同期し、使用者に一回一括認証の利便を与えます。
下記の図に、使用者認証と使用者同期アプリケーションの使用で起こる一連の事象を示します。
図 4.3.2-1: 使用者同期アプリケーションの処理流れ

使用者認証と使用者同期アプリケーションの使用で起こる一連の事象は:

使用者同期アプリケーションを開始して、使用者がログインします。



依頼者認証代理役が、状況参加（Join Context）トランザクションを状況管理役（Context Manager）に送って、CCOW 使用者状況に参加します。この時点で使用者
識別は状況に参加していません。



使用者は使用者名とパスワードを依頼者認証代理役に与えます。この認証情報は________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

42

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

Keroberous が使用する申込み・応答システムに変換され、ネットワークにパスワードが伝わるのを防ぎます。この情報は切符許可切符（Ticket Granting Ticket, TGT）を取得する使用者認証取得トランザクションの一部として使用されます。


TGT は依頼者認証代理役により保存され内部で管理されます。TGT は使用者が認証されていることを示す証明書として働きます。



状況変更（Change Context）トランザクションが、完全に確認された使用者名とともに状況管理役（Context Manager）に送られます。



使用者はこの時点で使用者状況参加者にログインします。



使用者がセッションを終えると、ヌル値（null）の使用者名で、状況変更（Change
Context）トランザクションが状況管理役に送られます。



使用者は使用者状況参加者から抜け（log out）ます。

4.3.3 複数アプリケーションでの迅速使用者切り替え処理流れ
臨床環境での使用のモデルは、複数の臨床家が同じワークステーションを一日に短い間隔で何度も使うことが特徴です。この様なワークステーション共有環境では、使用者は迅速にアプリケーション内の患者データを手にせねばなりません。OS レベルあるいはネットワ
ークレベルでの伝統的なワークステーションのログイン・アウトは時間がかかりすぎ、ア
プリケーションの終了も強制されます。これはアプリケーションの使用者がデータベースへの接続を初期化し新しい接続を樹立する必要があり得ることを意味し、臨床家の患者データの入手をさらに遅らせます。CCOW 標準、詳しくいえば使用者は、施設認証役（Enterprise Authenticator）と組み合わせ、アプリケーションで認証を受け、他のすべてのアプリケーションで自動的に認証されるようにできます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

43

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 4.3.3-1: 複数アプリケーション使用時の迅速使用者切り替え
処理流れは以下に類似の物となります:
臨床家Ａは、依頼者認証代理役を含むアプリケーションを介して業務を開始し、認証を受けます。この依頼者認証代理役は、使用状況セッションを開始し臨床家 A を使用者として状況に加えます。
臨床家Ａは、使用者状況参加者実行役を含む、臨床データ保管庫アプリケーションを開始
し、使用者状況参加者 1 となります。
臨床家Ａは、使用者状況参加者実行役を含む、心臓病学アプリケーションを開始し、使用者状況参加者 2 となります。この実行役は使用状況セッションに参加し、状況管理役から
現在の使用者を取得し、臨床家Ａを心臓病学アプリケーションにログインさせます。
臨床家Ａは、業務を行い、呼び出しを受けたのでワークステーションから離れます。
臨床家Ｂがワークステーションに近づき、依頼者認証代理役を使用して認証を受けます。
これにより OS レベルでのログインとログアウトの必要無しに、使用状況が臨床家Ａから臨
床家Ｂに設定されます。臨床データ保管庫と心臓病アプリケーションは使用状況の変更を________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

44

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

状況管理役から通知され、結果、臨床家Ａはこの二つのアプリケーションから出て、臨床家Ｂがこの二つのアプリケーションにログインします。
臨床家Ｂは心臓病アプリケーションでの患者データの閲覧を終了し、依頼者認証代理役を使用して、ログアウトします。これにより、使用状況が変更され現在の使用者が使用状況から削除され、使用者が心臓病アプリケーションからログアウトされます。

5. 患者識別相互参照（Patient Identifier Cross-Referencing, PIX）
患者識別相互参照（PIX）は、広範囲の大きさの医療機関（病院、診療所、医師執務所、など）を対象としたものです。以下の相互作用を介して、複数の患者識別圏からの患者識別の相互参照を可能とします。


患者識別を識別源から患者識別相互参照管理役への伝達



問合せ・返答、ないし、更新通知を介する、患者識別相互参照一覧表を入手する
能力

この統合プロファイルは特定の実行役の間でのトランザクジョンを規定しますが、施設の基本方針や相互参照の計算方法を指定しません。この様な振る舞いを一つの実行役に包含することにより、この統合プロファイルは必要な相互運用性を提供しながらも、施設が適切とする相互参照基本方針や計算方法が使用できる柔軟性を維持しています。
以下の図に、この統合プロファイルが意図する範囲を示します。

図 5-1: 患者識別相互参照での処理流れ
図では患者識別圏の二つの型を示します。患者識別圏と患者識別相互参照圏です。
患者識別圏は、共通の患者識別方式（識別子と患者への割り付け処理）と、患者識別子の________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

45

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

発行責任権限とを持つ、一個、あるいは、連携する複数システムの一セットです。さらに
患者識別圏は以下の属性を持ちます。


識別子をいかに定め、識別圏の特定の要求事項に従っていかに管理するかを記述した基本方針



圏内の、識別に関連した基本方針を統括する管理権限者



患者識別源システムとして知られる一個のシステムが、患者に関連する対象物の事例それぞれに一意の識別子を割り付けるとともに、識別特性の集合を維持します。



理想的には一つの患者識別圏の中では一つの識別子が一人の患者に一意に関連付けられますが、一個の患者識別源実行役が同一の患者に対して複数の識別子を割り付け、この事実を患者識別相互参照管理役に通知することもできます。患者識別相互参照管理役が、この様な重複を含む相互参照一覧の要求に如何に応答するかは、ITI TF-2a: 3.9.4.2.6 を参照してください。



患者識別子相互参照圏のなかで一意の識別圏識別子（割り付け権限者）



患者識別圏内の他のシステムは、それが属する患者識別源システムが割り付けた識別子に依存します。

以上の想定はこのプロファイルの実装を成功させるのに重要です。参加する患者識別圏への制限を最小にし、患者識別相互参照圏に対し、患者識別相互参照管理役の動作制限の大部分を中心化します。もし、上記項目に合意できない場合には、このプロファイルは予期される結果をもたらさないことがあります。
識別源実行役が提供する識別情報の品質改善には、患者識別相互参照管理役は責任がありません。患者識別相互参照管理役に高品質データを提供する責任は、識別源実行役にあるとされています。たとえば、患者識別相互参照役は、患者基本情報の一個の参照源となる責任はありません。この意図は、患者基本情報の品質と管理、および、使用する識別子の一貫性の責任をおのおのの患者識別圏（源実行役）に任せることにあります。複数の患者識別相互参照圏（PIX Domains）からの報告を受け表示する時、一部の報告や表示が一貫しない名前を持つことは避けられません。
患者識別相互参照消費役は、相互参照された一組の患者識別を問合せることも、相互参照の変更についての通知と問合せトランザクションの両方を使用こともできます。通知を使用する場合で、患者識別相互参照消費役が患者識別相互参照管理役と同期していない状況
では、患者識別相互参照消費役は PIX 問合せトランザクションも使用することもできます。
この統合プロファイルは PIX 問合せトランザクション（ITI TF-2a: 3.9）を使用する際の基本方針を定めていません。
この統合プロファイルと施設患者主索引（enterprise master patient index, eMPI）の関係についての討議は ITI TF-1; 5.4 を参照してください。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

46

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

5.1 実行役/トランザクション
図 5.1-1 に患者識別相互参照統合プロファイルに直接含まれる実行役と、関連する実行役間の関連するトランザクションを示します。他に関連のあるプロファイルに参加しているために間接的にこの統合プロファイルに含まれる可能性のある実行役は、図示されていません。

図 5.1-1; 患者士木部悦相互参照実行役の図
表 5.1-1 に患者識別相互参照統合プロファイルに直接含まれるトランザクションを示します。この統合プロファイルが使用可能と主張するには、実装製品は必須のトランザクショ
ン（”R”と表記）を実行できねばなありません。”O”と表記されたトランザクションはオプションです。この統合プロファイルで定められたオプションで、実装製品が選択可能な、
オプションの完全な一覧は、ITI TF-1: 5.2 にあります。
表 5.1-1: MPI プロファイルのための患者識別相互参照統合プロファイル－実行役とトランザクション

5.2 患者識別相互参照統合プロファイルオプション
この統合プロファイルに選択可能なオプションは、それに適用される実行役とともに、表5.2-1 に示します。
表

5.2-1: 患者識別相互参照プロファイル－実行役とオプション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

47

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

5.2.1 小児基本情報
予防接種登録や他の公衆衛生データベースの経験から、同一人に対する複数の異なった情報源から、小児の記録が多くを占める環境で、患者記録を対応させ連携させるには、追加の基本情報が必要であることがわかっています。
特に、双子、三つ子の様な場合の記録の区別－偽りの対応付けの回避－は、基本情報が二人の間で大部分が同じなため、困難なことがあります。たとえば、双子では同じ、姓、親、
住所、誕生日、名も似通って、一文字しか違わないことがあります。コンピュータはもちろん、人間の目でみても、名のわずかの違いが、単なる書き間違いか、二人の異なった記
録か、決めかねることがあります。この決定には追加の情報がきわめて重要です。
小児基本情報は以下の六個の追加基本情報データ野を使用し、多くの小児記録のデータベースで記録の対応付けを助けます。

小児基本情報オプションを使用可能とする患者識別源実行役は、患者識別管理[ITI-30]トラ
ンザクションを使用可能とせねばなりません。もし、小児基本情報の一個以上に患者識別管理[ITI-30]で値が特定されている場合には、この値は PIX 管理役の対応付け計算法の一部として考慮されねばなりません。
小児基本情報は、以下の全てと定められています。


母の旧姓名



患者の家庭電話番号________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

48

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________



患者多胎指標



患者生誕順



最終更新日付・時刻



最終更新施設小児基本情報は特に二つのデータ問題に焦点を置いています:

データあるいは検索条件が異なっているがデータと検索条件が同一人を示す
場合に、記録の所在を定める、および、



同一人に属していないが似通った記録を誤って関連付けるのを回避する

この問題は双子がよく似た名前を持っているときにもっとも多く遭遇します。

5.3 患者識別相互参照プロファイル処理流れ
この統合プロファイルが処理する使用例を以下に記述します。
5.3.1 使用例: 一施設内に複数の患者識別圏
総合病院で、ICU の臨床家が ICU 情報システムの患者カルテを閲覧していて、患者の血糖値を閲覧あるいは看視したいと思います。血糖値は、病院の主検査システムに保存されている検査レポートに含まれています。ICU 情報システムは自身が内部で生成した患者 ID を、
検査システムで患者 ID として使用されている、病院受付システム（ADT）が生成した医療
記録番号（カルテ番号、Medical Record Number, MRN）に対応付ける必要があります。
この例では、ICU システムは、それ自身の患者識別観念を持つので、病院の他の部署とは本質的に異なった患者識別圏です。
この想定業務手順では、病院の主 ADT システムは患者 ID として MRN を、患者識別配布（Patient Identity Feed）を使って患者識別相互参照管理役に提供します。同様に、ICU
システムは自身が内部的に生成した患者 ID と患者識別圏 ID とを、患者識別配布（Patient
Identity Feed）を使って患者識別相互参照管理役に提供します。
一旦、患者識別相互参照管理役は患者識別配布トランザクションを受けたら、受信した患
者識別配布トランザクションに含まれる情報をもとに、内部論理に従って、同一人であるとして「連結」します。相互参照の処理（計算法、人間による判定、など）は患者識別相
互参照管理役の内部で行われ、IHE の範囲外です（相互参照論理の限界範囲についてのよ
り詳しい論議は、ITI-TF-2a: 3.9.4.2.2.6 を参照してください）。
ICU システムシステムは、ICU システムでは患者 ID='MC-123'である患者の臨床検査の情報を取得したいと思います。検査システムに検査レポートを要求するときには、自身の患者 ID である'MC-123'、および、患者識別圏識別子と割付け責任機関を送信します。要求をうけとると、検査システムは、この要求が自己の識別圏（ADT 圏）以外の患者であると判断します。検査システムは患者 ID='MC-123'（ICU 圏内）に対応する別の識別子を患者識別相互参照管理役に要求します。
患者識別相互参照管理役は医療記録番号='007'として ADT________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

49

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

圏で知られている患者をこの患者に関連付け、ICU システムに患者 ID 対応表を検査システ
ムに送信し、要望する患者の検査報告書が取得できるようにして、ICU システムに返信します。図 5.3-1 に処理の流れを示します。

図 5.3-1: PIX プロファイルでの一施設内多患者識別圏処理流れ
注:

表示用情報取得トランザクションの部分はこのプロファイルの一部では有りませんが、図示の目的で含まれています。

5.3.2 使用例: 連携施設間での複数患者識別圏
二つの病院の連合からなる１個の医療施設が形成され、それぞれが異なった病院情報シス
テムで運営される独立した患者登録を持っているとします。患者が１個の病院で治療されたとき、もう一方の病院で管理される電子記録の利用が必要です。以下の使用例がこの想定業務手順を明らかにします。
病院 A と病院 B は連合しており、１個の患者識別相互参照管理役を持っており、二つの病院間で患者 ID の連携を維持しています。それぞれの病院は患者登録に責任をもつ異なった病院情報システム（HIS）を持っていますが、心臓病システムは連合しています。心臓病システムは、相互参照の活動が起こると、患者識別相互参照消費役が患者識別通知を受けるように設定されています。
病院 A で一人の患者が登録され、診断用の負荷試験を受けます。心臓病情報システムは、
過去の心臓病レポートが手にはいるか否かを知るため、この患者の別 ID の一覧を患者識別
相互参照管理役に問合せます。別の患者 ID はありませんでした。しばらくして、この患者が病院 B に行き、２回目の負荷試験を受けることになりました。病院 B の HIS を介して患________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

50

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

者は登録され、患者識別情報は患者識別相互参照管理役へ送られます。患者識別相互参照
管理役はこの患者が以前病院 A で登録された患者と実は同じ患者であると決めます。心臓病システムは以前に、患者識別相互参照管理役を使い通知を受け取る様に設定してあるので、通知が心臓病システムに送信され、患者 ID の対応付けを知ります。この通知は、患者識別圏を複数持つことを知っているシステムが、患者識別の変更が関知するいずれの患者
識別圏で起こっても、同期を維持することを可能にします。
図 5.3-2 はこの使用例の処理流れを示します。

図 5.3-2: PIX プロファイルでの、連携施設間での複数 ID 識別圏
注:

PIX 更新通知は最初の患者識別配布には送られませんが、これは、最初の患者識別配布トランザクションでは相互参照活動は起きないためです。

5.3.3 小児基本情報オプション使用例
以下の節に小児基本情報オプションが処理する使用例を記述します。
5.3.3.1 使用例: 出生登録からの高品質基本情報配布________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

51

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

地域予防接種情報システム(IIS)は、双子についての出生登録の情報を受け取ります。双子は”Lalainne”と”Lalannie” Smith です。受けとっと登録譲歩のすべてのデータ欄は値が入っており、名、出生順、出生証明書番号以外はすべて同一です。IIS 相互参照システムは非常に似たデータが二人の異なる個人に属することを、多胎の一人であること、出生順番号が異なること、出生証明書番号が異なることから、明確に同定できます。
5.3.3.2 使用例: 療養現場からの正常基本情報配布
２年後、この双子の母親は、離婚後に再婚して、小児保健施設に子供を連れて行きます。
そこで、２歳時の予防接種を受けます。小児保健施設は双子のそれぞれを登録し、登録結
果を IIS へ提出します。このデータは、新しい姓である"Gomez"が書かれていますが、事務員は正しく出生順を記録してあります。IIS は、母の旧姓が以前と今回の記録の両方に有りましたので、再び以前の記録と対応付けることができました。
5.3.3.3 使用例: 健康フェアからの最小限の情報
Jackson 郡の健康局は年一回の健康フェアを毎年８月にショッピングモールで開催しています。開催理由の一部は、学童期の子供が一年生に入学するのに最小限必要な予防注射のスクリーニングを行うためです。
母の Gomez は新しいアパートの家賃のため、働いており、彼女の義理の姉妹が子供を健康フェアに連れて行き、双子の”イエローカード”を持参したので、双子はそこで予防注射を受けました。Jackson 郡健康局の職員が双子の名前、施行し注射、を記録しました。翌日診療所でこのデータがコンピュータに入力され、地域 IIS 提出されます。
この時点で、双子の名前は、”Lane”と"Lanna"と誤表記されていましたが、予防注射登録は、個人基本情報が非常に似通っているものの、最終更新日／時刻がきわめて近く、最終更新施設が同じだったため、一個人ではなくて、双子の記録と再び認識することができました。残念なことに、健康フェアでは母親の情報が記入されず、義理の姉妹の名前と住所が記述されたので、予防注射登録はこの新しい情報を自動的に既に登録済みの"Lalainee"と"Lalannie"に結びつけることができませんでした。
他の可能性:

診療所で別のいくつかのデータ要素が記録いれば、もっと良い結果をもたらしたとでしょう。母の旧姓名（たとえ名のみでも）、家庭電話番号、健康局から送られた”イエローカード”に印字されていた固有識別子、のいずれかひとつがあれば、役だったでしょう。

5.4 PIX 統合プロファイルと eMPI の関係
PIX 統合プロファイルは別の患者識別圏の統合を、同一患者に関連する患者識別の間で相互参照する方法で、実現します。この節はマスタ患者索引（MPI）、施設患者索引（eMPI）
を作ろうとしている環境に以下に合致せせるかを議論します。eMPI は PIX 統合プロファ
イル実装のひとつの変形と考えられます。
MPI の構想は広い構想ですが、マスタ患者識別圏の作成と組になっています。このマスタ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

52

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

患者識別圏は、これに含まれる他の患者識別圏よりももっと広い範囲に、もっと大きい施設レベルで適用できると考えられています。このように患者識別圏をひとつのマスタ患者
識別圏に階層的にふくむ構造は患者相互参照の特定の例と考えられます。ここでは、種々の識別圏での患者識別はマスタ患者識別圏の患者識別に相互参照されます。可能な２つの設定法を図 5.4-1 に示します。

図 5.4-1: PIX 統合プロファイルと eMPI の関係
上の図 5.4-1 は典型的な MPI 方法によるマスタ患者識別圏（識別圏 C）は、患者相互参照
から考えると、単にもう一つの患者識別圏であることを示します。臨床データ登録所の様な施設全面にわたるシステムをいわゆるマスタ患者識別圏内に置くか否かの決定は単なる設定の選択です。さらに、このような設定は、識別圏 A 内のシステムは、識別圏 A の患者識別を管理するのみならず、識別圏 D の患者識別も知っています。この設定は、患者識別
相互参照プロファイルでは、有るシステムが複数識別圏を越えて動作するように設計・設定する様な設定と、同じになります。従って、MPI（楕円で示す）と言われる実体は、患者識別源実行役（ADT）と患者識別相互参照管理役との組み合わせと同じです。
PIX 統合プロファイル環境は、固有の MPI を配置する様に選択した環境と共存でき、いっそう大小変更自由な方法を提供します。他の多くの設定が可能ですが、特に、他の識別圏を「含む」マスタ識別圏の生成は必要ない設定も、あります。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

53

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

6. 患者同期アプリケーション（Patient Synchronized Applications, PSA）
患者同期アプリケーション（PSA）は一台のワークステーションのデスクトップで、一回の患者選択で複数のアプリケーションを使用できる様にします。この統合プロファイルにより、いずれかひとつのアプリケーションで患者を選択すれば、他のすべてのアプリケー
ションを同じ患者に向けることができます。これにより臨床家は自分の好みをひとつのア
プリケーション内で患者を選択し、他のすべてに反映できます。
このプロファイルは HL7 CCOW 標準、特に患者サブジェクト状況管理に影響を与えます。
このプロファイルの範囲は CCOW 患者サブジェクト共有のみです。この IHE PSA プロフ
ァイルは、PSA を使用可能とするアプリケーションの垣根を越えて患者識別の一貫性を補
強し、PSA を使用可能とするアプリケーションの垣根を越えた一貫性のある振る舞いのガ
イドを提供し、施設間で患者識別相互参照消費役との一貫性のある相互作用を確実にし、CCOW の患者サブジェクト定義の価値を高めます。
使用者認証の必要なアプリケーションでは、IHE は施設使用者認証（EUA）を、他の方法、
たとえば、CCOW 認証保管庫のような方法にかわって、推奨します。ITI TF-1: 4 に施設使用者認証（EUA）と CCOW 使用者サブジェクトの使用を記述しています。

6.1 実行役・トランザクション
図 6.1-1 は患者同期アプリケーションに直接含まれる実行役と、その実行役間の関連するトランザクションを示します。他の統合プロファイルへの参加のため間接的に含まれる他の実行役は示されていません。

図 6.1-1: 患者同期アプリケーションプロファイル実行役の図
表 6.1-1 は PSA 統合プロファイルに直接含まれる実行役のそれぞれに対するトランザクシ
ョンを示します。この統合プロファイルが使用可能と主張するには、実装品は必須のトラ
ンザクション（"R"表記）が実行できねばなりません。
患者状況参加実行役（Patient Context Particiopant Actor）は、ITI TF-2a に定められた様に、図 6.1-1 に示される４つのトランザクションを使用可能とせねばなりません。患者状況
参加実行役はあらゆる患者状況変化に対応せねばなりません。患者状況参加実行役は、も________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

54

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

し、アプリケーションが患者選択機能を持つなら、患者状況を設定せねばなりません。
IHE 状況管理役は、CCOW 状況管理機能よりも広い範囲を含包します。状況管理登録所や患者対応付け代理役のような他の要素を含みます。
状況管理役（Context Manager）は患者識別相互参照（PIX）統合プロファイルの患者識別
相互参照消費役と一括化できます；この場合の、状況管理役に課される追加の責任については、ITI TF-2x: 付録 D を参照してください。
表 6.1-1 患者同期亜ポリケーション統合プロファイル－実行役とトランザクション

6.2 患者同期アプリケーション統合プロファイルオプション
この統合プロファイルに選択可能なオプションを表 6.2-1 に、適用する実行役とともにしまします。オプションの間の依存はもしあれば、注に記述されます。
表 6.2-1: 患者同期アプリケーション－実行役とオプション

6.3 患者同期アプリケーション統合プロファイル処理流れ
患者同期アプリケーション統合プロファイルは２個以上のアプリケーションを同時に使用者が使用する必要があるときに最大の価値を提供します。ITI TF-1: 6.3.1 に概説された処理の流れは、アプリケーションが PSA にのみ参加する使用例を示しています。ITI TF-1:
付録 E に概説された処理の流れは、PSA と施設使用者認証（EUA）が同時に配置された場
合を示します。
6.3.1 使用例: 単純切替
PSA が EUA と一括されていないときは、患者識別のみが渡されます。この使用例では、使用者認証の方法を明示的に特定しませんが、アプリケーションが使用者認証を必要としないか、他の方法で認証されるからです。この使用例では両方のアプリケ－ションは同じ
患者識別圏を共有します。この使用例での処理の流れは:臨床家が臨床データ保管庫アプリケーションを立ち上げ、患者状況参加役 1 とされます。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

55

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

臨床データ保管庫アプリケーションが臨床家のデスクトップで状況に参加します。
臨床家は臨床データ保管庫アプリケーションで患者 A を選択します。臨床データ保管庫ア
プリケーションは患者 A の患者識別子を状況に組み込みます。
臨床家は心臓病アプリケーションを立ち上げ、患者状況参加役 2 とされます。心臓病アプ
リケーションは状況に参加し、状況から患者 A の識別子を得て、表示を患者 A に絞ります。
臨床家は患者 B を心臓病アプリケーションで選択します。この行動は心臓病アプリケーシ
ョンによる状況変更（Change Context）トランザクションを開始させます（患者状況参加
役 2）。すべての非惹起アプリケーションは状況追従（Follow Context）トランザクションを介して参加し、結果として選択された患者が臨床データ保管庫アプリケーション（患者
状況参加役 1）の中で表示されます。
臨床家は臨床データ保管庫アプリケーションを閉めます。臨床データ保管庫アプリケーシ
ョンは終了前に、状況から抜けます。
この使用例を、図 6.3-1 に示します。

図 6.3-1: 単純患者切替業務流れ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

56

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

7 時刻一貫性（Consistent Time, CT）
時刻一貫性（Consistent Time）統合プロファイルは、ネットワーク内の多くのコンピュータの時刻と時刻印が同期するさまにします。このプロファイルは中央値で誤差一秒以内の同期を定めます。これは多くのコンピュータに十分です。
時刻一貫性（Consistent Time）統合プロファイルは、多数の実行役やコンピュータで時間軸を同期させる機構を定義します。種々の基盤、保安、データ収集プロファイルが、複数のコンピュータ上での一貫した時間軸の使用を必要としています。時刻一貫性（ConsistentTime）統合プロファイルは、RFC 1305 に定められた Network time protocol（NTP）の使用が必要です。高位の時刻サ－バから時刻を得るため、時刻サーバが時刻クライアントと一括されている場合には、時刻クライアントは NTP を使用せねばなりません。時刻サーバと一括されていないある種の時刻クライアントは、SNTP を使うことができます。
このプロファイルは以前は放射線基本保安プロファイルの一部でしたが、これには他の種々の基盤での使用法があります。
注: このプロファイルは IHE 放射線テクニアカルフレームワークの一部、基本保安プロファ

イルに対応します。これは放射線システムのみならず必須です。IHE IT 基盤のなかの数個の統合プロファイルや Cardiology でも必須です。このため、このプロファ

イルは放射線領域から IT 基盤領域に移動されました。このプロファイ

ルの要求事

項には変更がないので、放射線基本安全拠点（Radiology Basic Secure Node）ある
いは時刻サーバを使用可能とするは実行役は、変更の必要が有りません。

7.1 実行役・トランザクション
図 7.1-1 は時刻一貫性プロファイルに直接含まれる実行役と、その実行役間の関連するトラ
ンザクションを示します。時刻一貫性を必要とする他の統合プロファイルへの参加のため間接的に含まれる他の実行役は示されていません。

図 7.1-1: 時刻同期プロファイル実行役の図________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

57

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

表 7.1-1 は時刻一貫性統合プロファイルに直接含まれる実行役のそれぞれに対するトランザクションを示します。この統合プロファイルが使用可能と主張するには、実装品は必須のトランザクション（"R"表記）が実行できねばなりません。
表 7.1-1: 時刻一貫性－実行役とトランザクション

7.2 時刻一貫性統合プロファイルオプション
この統合プロファイルに選択可能なオプションを表 7.2-1 に、適用する実行役とともにしまします。
表 7.2-1: 時刻一貫性－実行役とオプション

7.3 時刻一貫性処理流れ
この節は、時刻一貫性プロファイルに関連する典型的処理流れを記述します。
図 7.3-1 の処理流れで、時刻クライアント A と時刻サーバ B は一括されています。クライ
アントとサーバが一括されている時は、時刻の同期には内部機構を用います。

図 7.3-1: 時刻一貫性プロファイルでの基本的処理流れ
時刻クライアント B は時刻サーバ A との時刻同期を維持しています。時刻サーバ B は時刻
クライアント B と内部的に同期しています。時刻クライアント C は時刻サーバ B との時刻同期を維持します。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

58

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

NTP プロトコルはこの種の連続滝方式同期により、同期に必要なネットワーク時刻を供給
しています。達成される正確さはネットワーク機器とネットワーク結線配置、および、コンピュータのハードウェアとソフトウェア実装に依存します。時刻サーバと時刻クライア
ントは一括されて、連続滝方式の同期を提供し、ネットワーク交通量を減らします。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

59

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

8 患者基本情報問合せ（Patient Demographics Query, PDQ）
患者基本情報問合せ（PDQ）統合プロファイルは、使用者が定義した条件で患者情報サー
バに、複数の分散するアプリケーションから患者一覧を問合せ、患者の基本情報（およびオプションで来院ないし来院関連情報）を、直接アプリケーションに入力します。

8.1 実行役・トランザクション
図 8.1-1 は患者基本情報問合せプロファイルに直接含まれる実行役と、その実行役間の関連するトランザクションを示します。患者識別相互参照などへの参加のため間接的に含まれる他の実行役は示されていません。

図 8.1-1: 患者基本情報問合せプロファイル実行役の図
表 8.1-1 は時刻一貫性統合プロファイルに直接含まれる実行役のそれぞれに対するトランザクションを示します。この統合プロファイルが使用可能と主張するには、実装品は必須のトランザクション（"R"表記）が実行できねばなりません。"O"表記のトランザクション
はオプションです。この統合プロファイルで定義され、実装品で使用可能にできるオプシ
ョンの完全な一覧は、ITI TF-1: 8.2 にあります。
表 8.1-1: 患者基本情報問合せ－実行役とトランザクション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

60

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

8.2 患者基本情報問合せ統合プロファイルオプション
この統合プロファイルに選択可能なオプションを、適用する実行役都ともに、表 8.2-1 に示します。オプションの間に適用される依存関係があれば、注記されます。
表 8.2-1: 患者基本情報問合せ－実行役とオプション

8.2.2 小児基本情報 （訳者注: 節番号は 8.2.1 が正しい？）予防接種登録や他の公衆衛生データベースの経験から、同一人に対する複数の異なった情報源から、小児の記録が多くを占める環境で、患者記録を対応させ連携させるには、追加の基本情報が必要であることがわかっています。
患者の母の情報、家の電話番号は、データの質が不均一であるときには、情報の取得に役立ちます。
患者基本情報消費役が患者の識別を確認するのに使われるときは、他のある種の基本情報
データ野を、問合せへの返答に含めることは重要です。特に、双子、三つ子などの記録の区別を助けます。
小児基本情報は以下の六個の追加基本情報データ野を使用し、多くの小児記録のデータベースで記録の対応付けを助けます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

61

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

小児基本情報オプションを使用可能とする患者基本情報消費役は、患者基本情報問合せ[ITI-21]トランザクションで、小児基本情報問合せパラメータデータ野を使用可能とし、小児基本情報として特定されたデータ野に含まれるいかなる値も受け取り、処理できねばな
りません。
小児基本情報オプションを使用可能とする患者基本情報供給役は、患者基本情報問合せ[ITI-21]トランザクションで、小児基本情報データ野にある値との一致を見つけ、小児基本情報として特定されたデータ野に、値があれば、値を戻さねばなりません。
小児基本情報問合せパラメータデータ野は


母の旧姓名



患者の家の電話番号

小児基本情報は以下のすべてと規定されています。


母の旧姓名



患者の家庭電話番号

患者多胎指標



患者生誕順



最終更新日付・時刻



最終更新施設8.3 患者基本情報問合せ処理流れ
患者基本情報供給役は以下の機能を果たします:

施設内の他のシステム（たとえば、ADT 患者登録システム）からの患者登録と更新通信文を受け取ります。このシステムは別の患者識別圏のことも、そうでないこともあります。このプロファイルでは、患者基本情報供給役が更新された患者基本情報を取得する方法は扱いません。



情報の問合せに応答します。

基本情報を取得する特定の方法はこのプロファイルの範囲外です。患者基本情報供給役が最新の基本情報を有していることは前提条件です。最新の患者基本情報を取得できるひとつの方法は、オーダ実施役の様な、基本情報を維持したり取得する、他の IHE 実行役と一括することです。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

62

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

すべての例で、患者基本情報供給役は患者基本情報問合せ、あるいは、患者基本情報・来院情報問合せの要求を、患者異本情報消費役から、受け取り、基本情報（および、適切な場合には来院情報）を、問合せを発したアプリケーションが関係する単一の識別圏から返します。識別情報は、複数あるいは単一の識別圏から返せます；含まれる構造的な問題は、「多識別圏環境での患者データ問合せ」節（ITI TF-2x: 付録 M）を参照してください。
使用例 1: 患者情報の病床での入力
入院患者がベッドを割り付けられました。患者は確実な識別情報を提供することも、提供できないこともあります。看護師は病床で使用する医療機器に患者の識別情報を入力し、患者と割り付けられたベッドとを関連付けます。その医療機器は、患者識別情報
供給役に患者一覧を問合せます。看護師が入力する検索条件は以下の様です。


患者氏名の一部、または、全部



患者 ID（これは、患者診療録に印字、あるいは、病床カルテ、など）



患者 ID の一部の入力、あるいはスキャンで入力

生年月日・年齢増



ベッド ID

システムは、MRN、氏名の全部、年齢、性、室・ベッド、入院日を示す患者一覧を返し、看護師にリストを表示します。看護師は適切な記録を選択し、ベッドサイド機器のアプリ
ケーションに入力します。
使用例 2: 患者識別情報の医師執務室（医師オフィス）での入力
患者がはじめて医師執務室を訪れました。看護師は患者を登録せねばなりません。そこで患者の基本情報を実地医療管理情報システム（PMIS）に記録したいと思います。医師執務室は病院の中央患者登録と接続しております。看護師は病院の中央患者登録に、基本的な情報を間作条件にして、患者問合せを発行します。返答された患者リストから、看護師は患者に適合する記録を、病院患者 ID を含んで、拾い上げ、PMIS に入力します。（PMIS
は中央患者登録とは別の患者識別圏を使っていることに注意してください）
PMIS はそれ自身の患者識別子を使用して、患者一覧（病院の患者 ID 圏を共有）で返答された患者 ID と協働させ、病院の臨床保管庫からデータを取得します。
使用例 3: 複数患者識別圏をもち施設での患者基本情報問合せ
検査室技師はある基本的情報（たとえば患者氏名）を検査アプリケーションに入力して、臨床検査のために、患者基本情報供給役に問合せます。検査アプリケーションは検査結果を送信するため、別の患者識別圏の患者識別子が必要なので、アプリケーションは他の識別圏の患者 ID を問合せ結果から受け取るさまに設定されています。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

63

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 8.2-1: 患者基本情報問合せプロファイルの基本処理流れ
8.3.1 IHE の他の業務流れプロファイルと PDQ の組み合わせ使用
患者基本情報供給役が、患者情報整合性維持活動に参加する他の IHE プロファイルの実行役（たとえば放射線 PIR）と一括されると、PDQ 供給役は PDQ 問合せに対して更新された情報を使用できる様になります。くわえて、患者基本情報問合せプロファイルが他の IHE
プロファイルととともに、統合された業務流れの役割を担うことができます。
8.3.2 供給役データ設定
単一の患者識別圏で患者基本情報を保持する患者基本情報供給役は、その識別圏内で一致を提供せねばなりません。
患者基本情報供給役が複数の患者識別圏の患者識別情報を持つときは、MSH-5-Receiveing

Application、MSH-6-Receiving Facility と関連する識別圏の情報を返さねばなりません。
この使用例のより詳細な論議とこれを可能とする構造の説明は、「複数識別圏環境での患者
基本情報問合せ（PDQ）使用」節（ITI TF-2x: 付録 M）を参照してください。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

64

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

9 監査追跡と拠点認証（Audit Trail and Node Authentication, ATNA）
監査追跡と拠点認証（ATNA）統合プロファイルは、保安基本方針と手順とともに、患者情報の秘匿性、データ統合性、および、説明責任を提供する保安手段を確立します。

この

環境は安全圏（Secure Domain）と考えられ、部門、施設の規模から XDS 連携圏の規模まで適応可能です。ATNA モデルでは、安全圏内では以下が正しいです:1.

すべての機器は主催者（ホスト）に認証されています。
（これを達成する方法は種々あります。
）この認証により、既知の保安特性を持った、病院の保安システムに知られている機器であると同定します。未知の機器も利用を許されることもありますが、公衆や未知の機器に公開してよいと権威付けられている情報のみが利用できることに注意してください。
（患者は予約のような情報が未知の機器により公開される危険は受け入れるが、より微妙な PHI には公開を許さない様にする可能性があります。
）
2.

ホストの同定は、ホスト上の自動実行機能あるいは・またはホストの利用制限の指揮下にある人物に、どんな利用を許可するかを決定するのに使われます。実際には、
事前データ取得（pre-fetch)のような自動実行機能が重要な役を果たすため、使用者の認証と同定のみでは不十分です。
3.

安全拠点（secure node）は、合理的な利用制限を行う責任があります。これには典型的には使用者認証と権限付けがあります。使用者認証の価値は、得られる安全と追加認証手続きによる遅れが患者の療養に及ぼす影響とを、平衡させる必要があります。
4.

安全拠点（secure node）は、保安関連事例の追跡のため、監査記録の作成に責任があります。医療では厳格な利用制限よりも監査記録の方がしばしばより有用で、緊急事態でも信頼が置ける方法です。
このモデルは、書類が機器間で交換され受信側で保存される状況があるとの想定から、一部は動かされています。医療施設が災害や多数が殺到する状況でネットワーク運用が限られるか破壊された環境でも運用できる必要からも、一部は動かされています。依頼側（クライアント）が常に表示のみと想定するのは危険です。保持された情報の多くのコピーが半永久的に存在します。正常の運用でも医療提供施設は患者一人あたり 15 分
しか使えません。医療システムはネットワーク上での書類の検索と通信に時間を費やしてはなりません。書類は事前に送信され、必要が無くなるまで現場で保持されます。医療では表示のみのアプリケーションも存在し、故障しても安全や患者への危険を招来す
ることがない状況での使用に限定されています。完全な保安・プライバシー設計では、データの取得後にデータが保存される状況を扱えることが要求されます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

65

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________ATNA 統治想定
根底に有る想定は


安全圏（Secure Domain）の一員であるシステムは、ATNA プロファイルのため、安全拠点実行役（Secure Node Actor）を実装します。



安全拠点にあるすべてのアプリケーションは、IHE 実行役か否かにかかわらず、
ATNA 要求事項に準拠します。これは、PHI を生成、利用、更新、および削除する、すべての IT 支援下の活動に、
IHE で定められ IHE 実行役で行われたものに限らず、適応します。

IHE は IHE 医療アプリケーションの想定範囲内のシステムに関連する保安上の要求事項のみ扱います。IHE は、ネットワーク攻撃に対する防御、ウィルス感染などの他の保安要求事項を扱いません。監査追跡の主対象は PHI のデータ利用の追跡であり、トランザクションの追跡ではありません。



携帯機器も監査追跡と拠点認証（ATNA）統合プロファイルに参加できますが、このプロファイルでは携帯機器に関わる特別の問題は扱っていません。



ATNA は、施設を保安とプライバシーの規制に合致する様に、物理的利用制限、職員基本方針、その他の組織化された保安考慮が行われていることを、前提としています。

9.1 認証ATNA は、ネットワークを介する利用を拠点間にのみ制限し、それぞれの拠点の利用を権限のある使用者にのみ限定して、利用制限に貢献します。

１個の安全圏（securedomain）内の安全拠点（secure node）間のネットワーク通信は、その安全圏内の他の安全拠点との間のみに制限されています。安全拠点は現地の認証と利用制限の基本方針にもとづいて権限を付与された使用者のみの利用に限っています。
9.1.1 使用者認証
監査追跡と拠点認証（ATNA）統合プロファイルは、現場での使用者認証のみが必要です。このプロファイルでは、それぞれの安全拠点は、使用者認証にそれぞれの好みの技術を使用するのを許しています。施設使用者認証はこのような選択肢のひとつですが、
このプロファイルを使用せねばならないわけではありません。
9.1.2 接続認証
監査追跡と拠点認証（ATNA）統合プロファイルは、それぞれの拠点の間での往復の接続の認証に、双方向性の証明書基盤の拠点認証を要求しています。DICOM, HL7,
HTML はすべて証明書基盤の認証機構をさだめています。これらの機器への双方向性
証明書基盤認証でない接続は、禁止するか、PHI の利用を防ぐために設計され証明され________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

66

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

ねばなりません。
注:

IHE プロファイルで定められていない通信、たとえば、SQL サーバは、PHI に使用するのであれば、双方向性に認証されねばなりません。このプロファイルでは以下に認証するかは定めません。

この要求事項は完全な物理的保安と厳格な選定医管理により達成することもできます。
これは、信頼されていない機器がネットワークのいかなる部位にも手が付けられない事を意味します。接続認証を設定可能状態にすると、物理的に保安措置がとられたネットワークでは実行能力が増します。安全拠点実行役は、接続認証と物理的保安措置を講じたネットワークの両方に適合するよう設定可能でなければなりません。
IHE は伝送中の暗号化を必須としていません。多くの病院のネットワークは物理的および運用上の機構により十分な保安を提供しています。このようなネットワークでは、暗号化による実行速度の低下は正当化されません。このプロファイルは、他の権限付与された安全拠点とのみの通信を確実にするため、拠点間のすべての通信に TLS 安全交渉
（Security Negotiation）機構を使用することを必須としています。拠点の双方が暗号化を受け付け、暗号化が可能な様に設定されれば、暗号による交渉（negotiation）を許しています。これにより、IHE 安全拠点を他に安全措置のない環境に設置できる様になります。

9.2 監査追跡
使用者説明責任は監査追跡により提供されます。監査追跡は、施設の保安担当官が、活動を監査し、安全圏の基本方針に合致するか評価し、違反活動事例を検出し、保護下の健康情報（Protected Health Information, PHI）の不適切な生成、利用、変更と削除の検出が容易にできるようにします。PHI は患者を識別できる情報の記録（たとえば、登録、オーダ、検査、レポート、画像、および、画像表示条件）とされています。PHI
は使用者が利用したり、システムの間で交換されます。これには、安全圏（Secure
Domain）内のどの安全拠点へ輸出される情報や、どの安全拠点へ輸出される情報も、含まれます。
使用者説明責任は、標準に準拠した中央化監査記録保管庫によりさらに強化されます。
中央化監査記録保管庫は、もっとも単純な、保安要求事項をを実装する手段です。すべての IHE 実行役から監査記録保管庫に監査記録を送ることで改竄の機会を減らし、部門の監査を容易にします。接続を切断した拠点は、監査データを保存し、安全圏ネット
ワークへの再接続時に、記録を監査記録保管庫に転送します。
監査追跡は以下の様な質問に答える情報を含みます。
ある使用者には: どの患者の PHI が利用されたか？

ある患者 PHI には: どの使用者がりようしたか？

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

67

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________



どの使用者認証の失敗が報告されているか？



どの拠点認証の失敗が報告されているか？

監査追跡と拠点認証（ATNA）統合プロファイルは、プライバシー・保安規制（HIPPA、欧州、日本）に適合しようとする施設には有用なツールを提供しますが、プロファイル
自身が施設を適合化するわけでは有りません。監査記録の管理については、施設は NIST
SP 800-92-Guide to Computer Security Log Management のような文書を見てください。
9.2.1 監査通信文
保安とプライバシ保護の一部として監査を使用することは、関与する人員が信頼でき、急速に変化する状況に迅速に対応する広範な柔軟性を持つ状況に適切です。これは医療機関に典型的な環境です。監査では、何が起こったかを追跡しますが、関与する人々は監査されているのを知っています。これは、監査記録は事例の全体にわたる記述をとらえねばならず、それぞれの IHE 実行役に対応する個々の断片をとらえる事では無いことを、意味します。
IHE 監査追跡は異なった形式の利用制限と認証方法に対応する数個のプロファイルの最初のものです。監査は選択した利用制限や認証方法とは関係なく、常に必要なものです。
IHE が定める監査の流れを図 9.2-1 に示します。
1.

現実世界での活動が生じ、ある IHE プロファイルを使用可能とする機器の処理を行うアプリケーションを含むとします。この製品は特定の IHE 実行役に該当する要素を含みます。製品は IHE の推奨とは関係のない他の機能を持っています。

2.

この処理の過程で種々の事例が生じます。一部は IHE 実行役の活動に直接関連しますが、他は、IHE の仕様に関連ありません。事例は、キーボードの打鍵のようなきわめて詳細で些細な事例から、診断検査の分析のような高度のものまであります。
ほんの一部のみが保安とプライバシー監査に関連します。多くは低レベル過ぎて有益でないか、無関係です。

3.

「医療アプリケーションにおける安全監査と利用説明責任通信文 XML データ定義（Security Audit and Access Accountability Message XML Data Definition in
Healthcare Applications）」（RFC-3881）は、安全とプライバシーに関係する報告
事例の XML 方式を定めています。これは、ATSM, HL7, DICOM 標準規格機関とNEMA/COCIR/JIRA の安全およびプライバシ委員会との協働により定められました。IHE は RFC-3881 の仕様尾を推奨し、望ましい報告のみの事例に推奨します

4.

DICOM は監査通信文の語彙の一部を標準化しました。DICOM 監査通信文語彙は
RFC-3881 の基本語彙を拡張し、
RFC-3881 のオプション要素の一部を定めました。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

68

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

語彙の追加の例は、一個のデータ野が DICOM Study Instance UID を含むことを示す一個のコード化値を追加したことです。オプション要素の定義の例は、
RFC-3881 通信文の UserID データ野は現場の基本ソフト（OS）の使用者 ID で無ければならなこと、および、AlternateID データ野は施設使用者認証システムが使用する使用者 ID（もし前者と異なるなら）でなければならないことです。
5.

このプロファイルは DICOM 語彙が規定する事例と対応しない他の事例を定めます。これらの事例は RFC-3881 に記さされており、このプロファイルはそのような記述への要求事項を含みます。

6.

IHE 監査では、RFC-3881 の仕様に際し、DICOM 語彙で報告できる事例は、多々たとえ DICOM 適合機器でなくても、DICOM 語彙を用いて報告せねばならないとしています。DICOM 語彙に適合しない事例は、RFC-3881 語彙か他の拡張を用いて報告せねばなりません。

7.

現場施設は次に自身の報告基本方針を適用します。IHE プロファイルは監査報告に存在すべき機能を定め、さらに、現場施設の保安管理がレポートの詳細を制御できるようにすることを定めています。

8.

IHE は監査追跡で報告されるべき事例を定めています。これ以外に安全に関連する事例があり、これは監査追跡で報告できるか、他の方法で報告されます。このプロファイルでは、この様な事例を記述しませし、この様な事例にこの様式や機構を使用する様には定めていません。この様な事例として、OS 使用開始、ネットワーク
経路設定やファイアウオール記録です。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

69

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 9.2-1: 監査通信文に入れる事例の流れ
9.2.2 後方互換性
このプロファイルでは、廃止された IHE 放射線基本安全プロファイルからの IHE 暫定
監査通信文書式（IHE Provisional Audit Message Format）に合致するよう整えられた
通信文の継続使用を定めています。この古い書式は放射線科あるいは他の診断と治療活動の報告に適した事例を記述します。これらの事例は、RFC-3818 と DICOM 語彙により記述可能な種類の事例の部分集合です
ATNA プロファイルでは、暫定書式を用いてこれらの事例を、定められた転送機構がいずれであっても報告できる様にしています。この意図は、製品が暫定書式から
RFC-3181 への緩徐な移行にあること、移行には時間がかかること、すでに多くの実装があるからです。
他の医療アプリケーションでは暫定書式に関心があるとは思えないので、RFC-3831 様式と DICOM 語彙を使用せねばなりません。

9.3 監査追跡のサポート
監査追跡と拠点認証（ATNA）統合プロファイルは、監査記録通信文を記録する機構として、Syslog Protocol を使用する様、定めています。
既知の定められた２つの伝送があります。
1) Syslog 通信文を Syslog Protocol（RFC-5424）を用いて UPD（RFC5426）上で伝送________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

70

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

する。これには数個の限界が存在しますが、実際に重要な問題になったことは無いようです。


監査記録が目的で受信されたことの確認が送信側に後れない。



監査記録文を暗号化するオプションがない。



送信拠点の証明書を用いた認証と中央化した監査記録保管庫ができない。



通信文が中絶されたり、紛失することがある。

2) Syslog 通信文を、TLS で防護可能なストリーミングプロトコル上で Syslog 通信文を書式化する Syslog Protocol（RFC-5424）を用いて、TLS（RFC5425）上で、伝送する。

9.4 実行役とトランザクション
表 9.4-1 は監査追跡と拠点認証（ATNA）統合プロファイルに直接含まれる実行役のそれぞれに対するトランザクションを示します。この統合プロファイルが使用可能と主張するには、実装品は必須のトランザクション（"R"表記）が実行できねばなりません。"O"表記のトランザクションはオプションです。この統合プロファイルで定義され、実装品で使用可
能にできるオプションの完全な一覧は、ITI TF-1: 9.4 にあります。関連は図 9.4-1 に示します。

図 9.4-1: 監査追跡と拠点認証（ATNA）の図
実装品がこの統合プロファイルの実行役を使用可能とするときには、該当実行役は安全拠点（Secure Node）実行役と一括されねばなりません。この実装品では、すべての IHE 実
行役とその他の活動は監査追跡と拠点認証（ATNA）統合プロファイルが使用可能で無ければなりません。
実装品に必要な証明書を、たとえば、フロッピディスクやネットワークを介して、入れ込________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

71

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

むことができねばなりません。
非 IHE アプリケーションであっても PHI（Protected Health Information）を処理するものは、監査可能な事例を検出・報告し、利用を保護せねばなりません。
表 9.4-1: 監査追跡と拠点認証プロファイル（ATNA）－実行役とトランザクション

安全拠点（Secure Node）は以下を含まねばなりません:
1.

ITI TF-2a: 3.19 に定められた様に、私的情報を曝す可能性のあるネットワー
ク接続のすべての拠点認証トランザクション

2.

現場での使用者の活動（たとえば、ログイン、ログアウト）はすべて、権限を与えられた使用者のみが可能な様に、保護3.

監査事例を ITI TF-2a: 3.20 に記すように記録

安全拠点と安全アプリケーションの違いは、基礎にある OS、その他の環境が安全である範囲の違いです。安全拠点は、使用者認証、ファイルシステム保護、動作環境安全の全ての面を含みます。安全アプリケーションは動作環境を含まない製品です。安全拠点、安全ア
プリケーション、その他の関係については、ITI TF-1: 9.7 を参照してください。
1.

監査記録保管庫は以下を使用可能とせねばなりません:

2.

両方の監査伝送機構

3.

両者いずれか一方の伝送機構を使って送信するときには、IHE 規定の監査通信文書式。新しいアプリケーション領域は DICOM と IHE の語彙に加えて、独自の拡張語彙を持つことがあるのに注意してください。これにより、ATNA
監査記録保管庫は同時に、放射線基礎安全プロファイルの監査記録保管庫です。IHE 暫定通信文書式と BSD Syslog プロトコルの両者を使用可能とせねばならぬからです。

4.

自己防御と利用制限

このプロファイルは監査記録保管庫のその他の機能を規定しませんが、保管庫はスクリー
ニング、報告、保存などが可能であると予期されています。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

72

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

9.5 ATNA 統合プロファイルオプション
この統合プロファイルに選択できるオプションを、それが適用する実行役とともに、表 9.5-1に示します。オプションの間に依存がある場合には、注に記述されます。
表 9.5-1: ATNA－実行役とオプション

9.5.1 ATNA 暗号化オプション （退役）
9.5.2 放射線監査追跡オプション
放射線監査追跡オプションは、IHE 放射線実行役が送らねばならない監査事例に対する特定の要求事項を提供します。放射線実行役に基づくある種の監査事例の書式を特定します。

9.6 監査追跡と拠点認証処理流れ
監査追跡と拠点認証統合プロファイルでの安全手段には、使用者認証、拠点認証、および、
監査記録の生成があります。拠点認証と使用者認証は安全拠点（Secure node）の構想を樹立するトランザクションと安全圏（Secure Domain）内で、連結された安全拠点の集合を規定します。監査記録の生成には、監査きっかけ事象の組と監査記録内容の定義が必要です。このプロファイルは二つの容認できる通信文書式を規定します。
1.

IHE 監査記録書式に適合する通信文。これは、DICOM 監査通信文書式と IHE
拡張の両者の組み合わせです。RFC-3881 の IHE による拡張は、DICOM 規
格内にない領域で使用が必要な、事例コードと情報を追加します。

2.

前駆の IHE 暫定監査通信文書式。この書式は標準団体によって進められる共通監査通信文と語彙が定められるまでの間の書式として定められています。
ASTM（E2147-01 Standard Specification for Audit and Disclisure Logs for Use in
Health Information Systems）と HL7（Framework for audit Messagees）の成果に基づ
いて、IHE は監査きっかけ事象の詳細なセット、監査記録内容の一般的監査通信文のセット、および、一般監査通信文との対応付けを定めました。監査記録の内容は XML 方式により特定されています（ITI TF-2x:

付録 F 参照）。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

73

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

以下の段落では、認証された使用者、未認証の使用者、および、未認証の拠点が、保護下患者情報（Protected Health Information, PHI）に手を付ける状況での三つの典型的処理
流れを記述します。
9.6.1 正常拠点処理流れ
以下の想定業務では、ネットワーク内の認証された拠点からの PHI の認証された利用に際し IHE が如何に安全措置をとるかを示します。
1.

時刻同期は独立して起こります。このトランザクションはいつ起こっても良いです。正確な時刻が、正確な時刻刻印を持った監査記録の生成に必要です。

2.

使用者が画像表示役・安全拠点実行役にログインします。使用者は有効な信任状情報を入力し、拠点利用の認証を受けます。

3.

拠点は監査記録を生成します。

4.

使用者はある画像を問合せ、取得し、閲覧します。画像関連のトランザクシ
ョンが起こる前に、画像表示役・安全拠点と、画像管理役・画像保管庫との間で、認証が行われます。

5.

拠点認証のあと、拠点は問合せ・取得トランザクションを開始します。

6.

拠点が監査記録を生成します。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

74

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 9.6-1: 認証拠点での処理流れ

9.6.2 非認証拠点での処理流れ
以下の想定業務では、ネットワーク内の認証されていない拠点からの権限のない PHI 利用
から、IHE 安全措置が如何に防御を助けるか示します。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

75

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

1.

認証されていない拠点が、検査自動化管理役・安全拠点に情報を問合せます。
これは認証されていないため失敗し、監査記録が生成されます。

2.

認証されていない拠点が検査自動化管理役・安全拠点に認証の処理を試みます。これは、不正な拠点が提示する証明書を検査自動化管理役・安全拠点が信用しないため、失敗します。

トランザクションの順列は一つの例にすぎません。非認証の拠点からのトランザクション
は全く予測不能で、いかなる順序でもおきます。

図 9.6-2: 非認証拠点での処理流れ
9.6.3 非認証使用者の処理流れ
以下の想定業務では、医療機関内の認証されていない使用者からの PHI の権限のない利用を、IHE 安全措置が如何に防御を助けるか示します。
1.

認証されていない使用者が、心電図表示役・安全拠点に認証を試みます。これは、心電図表示役・安全拠点が使用者の名前と信任状情報が有効でない検出するため失敗し、監査記録が生成されます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

76

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 9.6-3: 非認証使用者の処理流れ

9.7 安全拠点、安全アプリケーション、他の実行役の関係異なった集団がシステムの異なった部分に責任をもつ場合には、安全拠点と一括された実行役の責任割り付けは複雑です。この様な状況はインターネットサーバアプリケーションの様に、OS、サーバ枠組み、個々のアプリケーションが存在する状況ではしばしば出現します。これらがすべて違った販売者によることがあります。それぞれの構成要素は保安関
連業務の遂行に、それぞれの役割を持ちます。これらの構成物を一個にまとめて最終的な完成システムにくみ上げる責任を持つシステム統括役も存在します。必要な保安機能が適切な構成要素にすべて実装されているのを確認するのはシステム統括役の責任です。
注: システム統括役は、システム販売者、外部コンサルタント会社、内部スタッフだったりしま
す。IHE は商売上の関係を規定しません。ここでの用語は機能的役割を示すもので、商売上の関係を意味しません。

IHE はこれらを二つの主要なカテゴリに分けます
医療機能:

IHE ではこれは実行役です。IHE は機能がどのように実装されるかは規定しません。複数の実行役が一個のインターネットアプリケーションに実装さされることも、一個の IHE 実行役の失踪に複数のインターネットアプリケーションを必要とすることもあります。IHE は機能を事項役に割り付けますが、この機能をそれぞれのインターネットア
プリケーションに割り付けるのは実装者の業務です。
基盤運用環境要素: IHE ではこれらの要素は安全拠点実行役です。安全拠点の機能をそれぞれどの要素に割り付けるかはシステム統合役が決めます。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

77

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

製品が安全アプリケーションを使用可能であると主張することは、IHE 業務に適切な機能を遂行できると主張しているのと同じです。これには、監査責任、通信保安責任、その他の保安責任のある部分を含むことになります。この様な責任の仕様は該当製品の機能とオプションに依ります。たとえば、使用者ログイン機能を持つ製品は、使用者に関連する監査事例を生成し、使用者認証を遂行します。対照的に、一個の機能をもつインターネット
アプリケーションは、その機能に関連する監査通信文のみを生成し、その他の機能については外部の安全拠点環境に依ります。
このことは、システム統括役は必要な保安機能の全てが存在するか否か判断すれば足りることを意味します。もし単一目的のインターネットアプリケーションが、拠点認証にイン
ターネットサーバ環境に依存するなら、システム統括役に、このことを明確にしないとなりません。すべてのインターネットサーバ環境が認証を提供するわけではないので、シス
テム統括役は、必要なときに認証ができることを確認せねばなりません。
製品にどのような保安特性が実装されているかを記述する際には、以下の規則が適用されます。
1.

製品が安全拠点実行役を持つと主張するときは、全ての OS およびその他の安全特性環境がすべて整っている様に統合されていなければなりません。

2.

製品が安全アプリケーション実行委役のみを持つと主張するときは、アプリ
ケーションの特性に適用される保安特性のみが提供されていることを示します。

製品を選択する場合には、製品が提供する保安特性のまとめの一覧として IHE 適合宣言が使用できます。アプリケーション製品が単に安全アプリケーションのみであるときには、安全拠点が提供する機能を樹立するのに必要な追加の製品や統合作業があるか決めるのに、
システム統合役はこの情報を使用できます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

78

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

10. 施設間書類共有（Cross-Enterprise Document Sharing, XDS.b1）
施設間書類共有（Cross-Enterprise Document Sharing, XDS.b）
IHE 統合プロファイルは、施設間での患者の電子健康記録の登録、配布、利用を容易にします。
施設間書類共有は、医師個人診療室、診療所から急性期入院施設まで、いかなる種類の施設間での、標準に基づいた書類共有管理の仕様を提供することに注力しています。
IHE テクニカルフレームワークの残りの部分では、XDS は一般的にあらゆる種類の XDSを指しますが、現状では XDS.b のみのことです。
XDS.b IHE 統合プロファイルでは、医療施設は一個以上の XDS 医療連携圏に属することを前提にしています。XDS 医療連携圏とは、共通の基本方針と共通の基盤の上で、協働することを合意した医療機関の群れです。
XDS 連携医療圏の例には以下があります:

任意の地域に属する全ての患者に医療を適用するために、地域情報機関が支える療養共同体



国規模の電子健康録（EHR）



専門あるいは疾患特化の療養

心臓病専門医と急性心臓病センター



腫瘍ネットワーク

糖尿病ネットワーク

医療施設の連合

数個の病院と療養施設からなる地域の施設連合



政府所管の施設（VA, 軍）[訳者注；日本では国立病院機構が該当]

保険会社支援共同体

XDS 連携圏では、ある種の共通基本方針と営業規則が定められねばなりません。これには、如何に、患者を識別するか、同意を取得するか、利用を制限するか、臨床情報の書式・内容・構造・組織化・提示をどうするかを定めねばなりません。この統合プロファイルは特定の基本方針や営業方針を定めませんが、広い範囲の基本方針に適合できる様に設計されており、患者臨床データ共有のための標準に依拠した基盤の配備を容易にします。任意の
XDS 連携圏内でひとりの患者の情報の縦断的記録を作成するには、国規模の書類保管庫と書類登録所による管理が必要です。これらは別物で、責任も別々です。:


書類保管庫は、透明性のある、安全な、信頼のおける、永続的な書類保存と書類取得要求への返答に責任を持ちます。



書類登録所は一人の患者の療養に必要な書類が、どこに保存されているかに

1

XDS.b とここでは記されますが、テクニカルフレームワークの以前の版では XDS.a があったためです。
TF 第 7 版では XDS.a は廃止されました。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

79

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

拘わらず、容易に見つかり、選択でき、取得できる様に、書類保存に関連する情報を保存する責任があります。
XDS では書類の概念は文字情報に限定されません。XDS は書類内容に依存せず、内容や表示に関わりなく、いかなる種類の臨床情報も使用可能とします。これにより、XDS IHE 統
合プロファイルは、単純テキスト、様式化テキスト（たとえば、HL7 CDA 第一版）、画像（たとえば、DICOM）、構造化され語彙がコード化された臨床情報（たとえば、CDA 第二版、CCR、CENENV 13606、DICOM SR）を等しく扱うことができます。書類源と書類消費役の間で、XDS は書類の形式、構造、と内容について、基本方針を採用しなければな
りません。
XDS 統合プロファイルは、全ての施設間電子健康録通信の要求に応えるものではありません。いくつかの想定業務では、患者識別相互参照（PIX）、監査追跡と拠点認証（ATNA）、施設間使用者認証（XUA）、表示用情報取得（RID）の様な、他の IHE 統合プロファイルの使用が必要となります。他の想定業務では部分的にしか使用可能でないもの、将来の IHEの統合プロファイルを要するものがありますが、IHE は基礎となる標準が定まり次第、できるだけ早く統合プロファイルを定めます。特に以下があります:1.

アレルギー一覧、投薬一覧、問題一覧、のような動的情報の管理は XDS では扱いません。しかし、表示用情報取得（RID）では、いくつのトランザクション（たとえば、
LIST-ALLERGIES, LIST-MEDS）ではこの機能の基礎的なものを提供しています。この様な動的臨床情報の更新管理とアプリケーションによる構造化された利用の追加手法は、将来、別の統合プロファイルとして策定されると思われます。

2.

オーダの発行と追跡（薬品の処方や放射線オーダなど）は XDS では使用可能ではありません。このことは、患者健康録に記録する必要がある場合には、XDS をオーダとその結果を保存するのに使用できないということではありません。しかし、XDS は業務の進捗情報を追跡する能力がありませんので、オーダ管理には使用できません。施設間でのオーダ業務流れ（e 処方、e 紹介）の追加的実現手法は将来別の統合プロファイ
ルとして策定されると思われます。

3.

XDS 連携圏の運用には、適切な安全モデルが存在することが要求されます。安全モデルの階層が準備されると期待されます。XDS には特定の安全モデルを組み込みも、必要ともしませんが、XDS 実装者は XDS 実行役と監査追跡と拠点認証（ATNA）からの実行役とを一括するよう、予期されており、この様な施設間環境で動作する利用制限も必要です。XDS を補完する別のプロファイル（たとえば、施設間使用者認証（XUA）、
書類デジタル署名）が使用可能です。

4.

独立した XDS 連携圏の設立が行われると、患者が地域間や国の間で移動することが予期されるので、これらの連合が必要になります。IHE は一つの XDS 連携圏から他の連携圏に情報を転送する必要、一つの XDS 連携圏から他の XDS 連携圏に管理されてい________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

80

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________る書類を利用できる様にする必要を、予見しています。XDS はこの拡張を念頭に設計されています。XDS を補完する共同体間利用（Cross-Community Access, XCA）は、
この機能を提供します。
5.

XDS は XDS 連携圏の管理や設定を扱いません。たとえば、ネットワークアドレスの設
定や、どの種類の臨床情報を共有するかは、XDS 連携圏が定める基本方針に任されています。

10.1 実行役とトランザクション

図 10.1-1b: 施設間書類共有－b(XDS.b)の図
表 10.1-1b: XDS.b－実行役とトランザクション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

81

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

注１: 患者 ID の割り付け責任機関が患者識別配布（Patient Identity Feed）、
患者識別配布 HL7V3（Patient
Identity Feed HL7V3）に依存するときは、患者識別源は、患者 ID 割り付け責任機関を識別するため、OID を使用せねばなりません。
注２: 書類登録所と患者識別源は、患者識別配布（Patient Identity Feed）、患者識別配布 HL7V3（Patient
Identity Feed HL7V3）の少なくともいずれか一方を実装せねばなりません。

10.1.1 実行役
10.1.1.1 書類源
書類源実行役は、書類の製造、発行元です。これは書類保管庫実行役に書類を送る責任があります。これは、書類保管庫実行役にメタデータを送り、次いで書類登録所実行役に送ります。
10.1.1.2 書類消費役
書類消費役は書類登録所に条件に一致する書類を問合せ、書類保管庫から選択した一個以上の書類を取得します。
10.1.1.3 書類登録所
書類登録所実行役は、登録された書類のそれぞれについてのメタデータを書類登録に維持します。これには、書類保管庫の書類が保存されている場所へのリンクが含まれます。書
類登録所は、特定の条件を満たす書類の書類消費役からの問合せに応答します。これはまた、書類登録時に医療に特異の技術的基本方針を補強します。
10.1.1.4 書類保管庫
書類保管庫は、書類の永続的保存と、適切な書類登録所への登録とに、責任を負います。
これは、事後の書類消費役による取得のため、uniqueId を付与します。
10.1.1.5 患者識別源
患者識別源実行役は、それそれの患者を一意に同定する識別子を提供し、識別特徴の集合を維持します。患者識別源は、他の実行役との相互作用において、登録所実行役による患者識別の証明を容易にします。
10.1.1.6 統合化された文書源・文書保管庫統合化された文書源・文書登録所は、文書源と文書保管庫の機能を併せて一つの実行役にまとめたものですが、書類セット提供・登録（Provide and Register Document Set）トラ
ンザクションを開始も受け取りもしません。書類セット登録または書類取得トランザクシ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

82

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

ョンの観点からは、書類保管庫実行役を置き換えるものです。
10.1.2 トランザクション
10.1.2.1 書類セット提供・登録（Provide and Register Document Set）
書類源実行役は書類セット提供・登録トランザクションを開始します。提出されたセットのそれぞれの書類について、書類源実行役は、書類を無意味 8 個組流れ（opaque octet
stream）として送るとともに、対応するメタデータも、書類保管庫に送ります。書類保管
庫はこの書類を持続的に保存する責任があり、書類登録トランザクションを用いて、書類源から受信した書類メタデータを転送して、書類を書類登録所に登録します。
10.1.2.2 書類セット登録
書類保管庫実行役は、書類セット登録トランザクションを開始します。このトランザクシ
ョンは、それぞれの登録書類に関するメタデータを供給して、書類保管庫実行役が一個以上の書類を書類登録所に登録できる様にします。このメタデータは文書登録所のなかに文書登録記録（Document Entry）を作成します。書類登録所は、登録のまえに、メタデータが有効であることを確認します。一個以上の書類メタデータが有効でないと、書類セット
登録トランザクション全体が失敗します。
複合書類を可能とするため、XDS 書類は複数部分からなる書類であることがあります。文
書保管庫は、複数部分書類セットを「不透明実体（opque entity）」として扱えねばなりません。文書保管庫は、XDS 統合プロファイルの状況では、複数部分書類の構造や内容を、いかなる部分であっても解析したり処理する必要はありません。
10.1.2.3 意図的に空白
10.1.2.4 登録所保存済問合せ
登録所保存済問合せは書類消費役が、療養提供者（EHR-CR）のため書類登録所に対して発行します。書類登録所実行役は療養提供者が指定した条件に合致する書類の所在を登録所で見つけます。書類登録所実行役は、条件に合致する文書登録の一覧を含む登録所メタ
データを返します。メタデータには、リストに対応する、一カ所以上の書類保管庫にわたる書類それぞれの所在場所と識別子が含まれます。
保存済問合せでは、問合せの定義は書類登録所実行役に保存されます。問合せを開始する
ため、問合せに関連する識別子が、問合せで定められた問合せパラメータとともに伝達されます。これは、以下の利点を持っています。
1.

悪意のある SQL トランザクションが導入されることが有りません

2.

代わりのデータベース形式と方式が書類登録所で使用できるようになります。これは、SQL 問合せがデータベースのテーブル配置に直接関係するからです。
このプロファイルは保存済問合せがどのように書類保管庫に組み入れられ、あるいは、実装されるかは定めません。
10.1.2.5 意図的に空白________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

83

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

10.1.2.6 患者識別配布
患者識別配布（Patient Identify Feed）は患者の識別子と裏付けとなる患者基本情報を、患者識別が確立したときに取られたデータ、あるいは、裏付けとなる患者基本情報が変更あるいは統合されたときに取られたデータをもとに、伝達します。XDS 統合プロファイルでの目的は、XDS 連携圏で登録された患者識別情報で、書類保管庫を埋めることにあります。
HL7 第２版用は ITI TF-2a: 3.8 に、HL7 第３版用は ITI TF-2b: 3.44 に、定められた患者
識別配布（Patient Identify Feed）は、標準の HL7 患者識別コード化を使用します。これは HL7 アプリケーションの標準コード化です: 受信側は使用に際して必要なデータを抽出するよう期待されています。
他の XDS トランザクションと結んだ場合、患者識別子を有する HL7 データを受信した書類登録所実行役と他の実行役は、HL7 通信文で受けたデータを、これらの XDS トランザク
ションで規定された書式に対応付けねばなりません。このトランザクションでは患者 ID は
ebXML コード化規則で扱われ HL7 符号化規則では扱われません。とくに患者 ID はストリングとして扱われ、ストリングに余分の要素が加わると、トランザクションを失敗させねばなりません。XDS 実行役は、他のトランザクションでは患者 ID 値については特定の符号化規則を使用せねばならず、HL7 トランザクションで受けた値そのままのコピーではありません。
XDS.b 実装品は患者識別配布（ITI TF-2a: 3.8）
、または、患者識別配布 HL7 V3、または、両者を使用可能とせねばなりません。相互運用性確保のため、単一圏あるいは単一共同体
では HL7 の版は実装された XDS.b と患者識別配布とで同じでなければならないことに注意してください。両者が混在する想定業務では、患者識別配布（ITI TF-2a: 3.8）と患者識別配布 HL7 V3（ITI TF-2b: 3.44）の間での通訳が、ブリッジあるいはインターフェースエ
ンジンとして、必要となります。
10.1.2.7 文書セットの取得
書類消費役は文書セット取得（Retrieve Document Set）のトランザクションを開始します。
書類保管庫は書類消費役が決めた文書セットを返さねばなりません。
10.1.3 XDS 書類内容サポート
以下の表に、種々の連携圏で臨床書類を共有する内容物を定める、他の IHE 統合プロファ
イルで使用可能な 2,3 の書類内容を示します。これらのプロファイルは XDS プロファイルの上に作られており、その特定の使用例の中で、施設間書類共有に追加の制限と意味を定めることがあります。
表 10.1-1: 使用可能な IHE 統合プロファイルと書類タイプの一覧________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

84

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

10.2 統合プロファイルオプション
この統合プロファイルに選択可能なオプションの一覧を表 10.2-1-b に、適用される実行役
ともに、示します。オプションの間にもし依存があれば、注に記述されます。
表 10.1-2-1b－実行役とオプション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

85

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

注 1: 書類登録と患者識別源は、少なくとも、患者識別配布、または、患者識別配布 HL7 V3のいずれか一方を実装せねばなりません。
注 2: XDS.b 書類登録所は、登録した文書が XDS 連携圏語彙からの confidentialityCode を含
むか、常に実証せねばなりません。BPPC プロファイルはこの XDS 連携圏定義語彙の一部の構造を与えています。

10.2.1 書類置き換えオプション
このオプションでは、書類源あるいは統合化書類源・保管庫は、登録所・保管庫に既存の文書を置き換える別の文書を提出する機能を提供せねばなりません。書類消費役との一括は、置換え用書類の提出で使用する、最新のメタデータと識別子を取得するのに使用できます。
10.2.2 書類追補オプション
このオプションでは、書類源あるいは統合化書類源・保管庫は、登録所・保管庫に既存の文書に追加する文書を提出する機能を提供せねばなりません。
10.2.3 書類変換オプション
このオプションでは、書類源あるいは統合化書類源・保管庫は、登録所・保管庫に既存の________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

86

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

文書を変換した文書を提出する機能を提供せねばなりません。
10.2.4 フォルダ管理オプション
このオプションでは、書類源は、以下の操作が実行できる機能を提供せねばなりません。


フォルダの生成2

ひとつのフォルダに１個以上の書類を追加

注: 既存のフォルダへの書類追加を可能とするには、書類登録所に問合せをするため、書類消費役との一括が必要なことがあります（たとえば、既存のフォルダの UID）。
10.2.5 非同期インターネットサービス交換オプション
このオプションを可能とする実行役は以下を可能とせねばなりません:

書類源実行役は非同期インターネットサービス交換オプションを、書類セット提供と登録トランザクション－b [ITI-41]で使用可能とせねばなりません。



書類消費役実行役は非同期インターネットサービス交換オプションを、登録所補完済
問合せトランザクション[ITI-18]と書類セット取得トランザクション[ITI-43]とで使用可能とせねばなりません。



書類保管庫実行役は非同期インターネットサービス交換オプションを、書類セット提供と登録－b トランザクション[ITI-41]と書類セット登録－b トランザクション[ITI-42]とで使用可能とせねばなりません。



書類登録所実行役は非同期インターネットサービス交換オプションを、登録所補完済
問合せトランザクション[ITI-18]と書類セット登録－b トランザクション[ITI-42]とで使用可能とせねばなりません。

非同期インターネットサービス交換オプションの使用は、個々の組み込み環境と連携圏の基本方針とで決まります。非同期インターネットサービス交換の説明は、ITI TF-2x: 「V.5
同期、および、非同期インターネットサービス交換」節を参照してください。

10.3 統合プロファイル処理流れ
典型的には一人の患者は、異なる療養状況での受診を順番に受けます。それぞれの療養状況で、結果的に生じる患者情報が生成され、複数の療養提供情報システム（Care delivery
information system, EHR-CRs）で管理されます。療養提供を順番にこなすと、多数の臨床書類が生成されます。EHR-LR は、同じ XDS 連携圏の一員である多種の EHR-CR が
EHR-LR に寄与しているため、これら書類の一部の重要なセットを共有する手段を提供し
ます。
例:

2

心臓病患者管理想定業務「フォルダ」は医療からきたもので、普通は特定の目的のために患者記録をフォルダに分けて入れます。コンピュータ科学の用語ではこの概念は UNIX のディレクトリ書式に近いです。ひ
とつのファイルを同時に複数のフォルダ内に置くことができます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

87

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 10.3-1: 心臓病患者管理想定業務のトランザクション処理流れ
この想定業務は、３週間の心臓病のエピソードに渉ります。息切れ、悪心、疲労感、胸痛で、患者は主療養機関（primary car provider、PCP）を受診した。この医師は、患者診療の改善のため PCP、 心臓病専門医、検査機関、および二つの現地病院が臨床書類を共有できる心臓病療養ネットワークを立ち上げた病院と密接に業務しています。この心臓病ネットワークは、この共同体に設置された地域療養データ交換共同体の一部で、どのケアプランにこの患者が属すか、患者はこのネットワークに属すように奨励されました。
この患者は健康記録番号を与えられました。
1.

患者の診察で PCP 医師は患者の訴えを記録し、患者は心電図を受けるべきと決めます。
医師は心臓病療養ネットワークに、このネットワークがきめた心電図レポートに対応
する、コード化された書類種別”report”、コード化された診療種別”cardiology”を入力して、患者の以前の心電図が有るか否か問合せます（図 10.3-1 のステップ 1）。一致した書類の中から、医師は以前の心電図レポートを見つけ取得します（図 10.3-1 のス
テップ 2）。医師は２つの心電図を比べ、心臓病専門医へ紹介すべきと決めます。医師は追加のレポートを心臓病療養ネットワーク内で探します（図 10.3-1 のステップ 3）が、なにも有りません。
携帯 EHR システムを使用して、患者の健康録口座番号に、３つの新しい書類（受診記
録、紹介状、新しい心電図レポート）と、以前の心電図レポート（図 10.3-1 のステップ 4）への参照からなる、”PCP 診察室受診”の書類セットの提出要求を出します。心臓________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

88

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

病専門医との連携を容易にするため、心臓病療養ネットワーク XDS 連携圏の基本方針
に従い、"Cardiac assessment"フォルダを作成し、この４つの書類を含ませます。
携帯 EHR システムが使う書類保管庫は、書類提出要求の一部にあたる書類を登録します（図 10.3-1 のステップ 5）。

1.

図 10.3-3: PCP 問合せトランザクション処理流れ

PCP EHR システムは、書類消費役と書類源実行役を実装しており、問合せ、取得、および、提供と登録の各トランザクションを、図 10.3-2 の様に、発行します。トランザ
クションは心臓病療養ネットワークが提供する書類保管庫と書類登録所が処理します。
2.

患者は心臓病専門医の受診予約を組みます。患者は検査室に行き、受診の前に必要な検査を受けます。検査所は臨床コード"laboratory test"の提出セットを作成し、検査結果を含ませます。検査室は”cardiac assessment”フォルダは知りません。

3.

心臓病専門医は患者を診察します。専門医は”cardiac assessment”フォルダ内で患者記録を問合せます（図 10.3-1 のステップ 1）。使用可能なのは、PCP の診察記録、心電図と以前の心電図、紹介状で、これらを取得し閲覧します（図 10.3-1 のステップ 2-5）。
専門医は最近の検査報告書を問合せ、検査結果を見つけます（図 10.3-1 のステップ 6）。
これを取得して閲覧します（図 10.3-1 のステップ 7）。
心臓病専門医はエコーを施行し、診察記録を口述し、負荷心筋シンチをオーダします。
診察記録、心臓エコー検査の画像とレポートが"cardiologist office visit"提出セットとして登録され、"cardiac assessment "フォルダに置かれます。加えて、検査報告書が"cardiac assessment "フォルダに追加されます（図 10.3-1 のステップ 8）。

4. 患者は放射線施設で核医学負荷検査のため診察されます。検査が行われ放射線科医がレポートを口述します。核医学検査レポートは、"radiology examination"提出セットとして登録され、"cardiac assesssment"フォルダと連携されます。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

89

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

5. 患者は２日後に心臓病専門医の診察を予約したが、激しい胸痛で目覚めます。働きに行
く途中で、患者は病院の緊急処置室（ER）を受診します。ER 医師は病院 EHR システ
ムを利用して心臓病療養ネットワークの登録所と保管庫に、患者に関連する種類を時間の流れを逆にたどって、問合せます（図 10.3-1 のステップ 1）。最新の心臓関連フォルダで使用可能な書類は、PCP と心臓病専門医の診察記録、最近と以前の心電図、検査
結果、核医学負荷試験とレポートです。
ER 医師は二つのもっとも重要なレポートを取得し、閲覧します（図 10.3-1 のステップ2, 3）。
ER 医師は検査、心電図、をオーダし、患者を監視下に置きます。検査と心電図は病院の EHR 内に置かれ、心臓病療養ネットワークの書類保管庫としても振る舞います。異常な心臓の活動（訳者注: 心電図のことであろう）は心臓カテーテル、診断、おそらくは心臓インターベンションも必要です。ER 医師は患者を心臓病サービスへ入院させ、心臓病専門医と連絡を取ります。

図 10.3-4: ER 問合せトランザクション処理流れ
6. ER 医師と相談中に心臓病専門医は自宅から心臓病療養ネットワークを利用します。患者の関連する、この医師の最初の診察以降のすべての書類を問合せます。彼が以前に知らなかった心臓核医学検査レポートが、ER の心電図とともに使用可能です。二人の医師（心臓病専門医と ER 医師）は患者の診療方針を決め、心臓病専門家は病院で患者を診る手配をします。
7. 患者が ER から移送されたとき、ER 診察記録が"emergency department visit"提出セッ
トとして提出され、新しく作成された"cardiac treatment"フォルダに、検査結果または心電図結果とともに、置かれます。
8. 患者は入院患者ベッドに移送され以下の出来事が順番に起こります

カテ室での心臓カテーテル検査が予定されます________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

90

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

追加の検査オーダが出され実行されます

カテ室で診断手技が行われます。



ステント留置が行われます

心カテインターベンションレポートが口述されます

患者は監視下の病床へ戻ります

教育が患者と家族に行われます

心臓病専門医が退院要約を口述します

心臓病専門医は予定の退院後来院日前に完了すべき検査をオーダします。



入院時評価、検査結果、心カテインターベンションレポートとキー画像、退院サマリーは"cardiac treatment"提出セットを形成し、心臓病療養ネットワークの、ERから始まる"cardiac treatment"フォルダに登録されます。

9. 患者は退院後経過観察のため、心臓病専門医を受診します。診察記録、心臓リハビリと要約が"cardiology office visit"提出セットに置かれ、心臓病療養ネットワークの"cardiac
treatment"フォルダに置かれます。
10. 患者は心臓病専門医がたてた予定に従いリハビルテーションを受けます。患者は回復し、PCP で診察をうけ、心臓病専門医に定期的に通院します。

10.4 一般的原則
10.4.1 EDR-CR 構想
HER-CR、あるいは療養提供記録は、療養提供組織の情報システムを抽象化したものです。
このシステムは、広い範囲の種々医療機関、たとえば、診療所、養護施設、外来診療所、急性期入院施設、などを支えます。
下図に示す様に、患者は典型的には、異なる療養状況での受診を順次行います。

図 10.4.1-1: 療養提供施設間での受診の連鎖提供される療養の形を定めたり制限したり、療養提供施設での内部の業務流れを定めたり________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

91

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

制限することは、この IHE 統合プロファイルの範囲外です。HER-CR システムは、施設間臨床情報共有に、単に書類源実行役、あるいは、書類消費役実行役として、以下の原則に則り、参加するのみです:
1.

EHR-CR は XDS 連携圏で使用可能な書類形式（たとえば、CDA 第一版、CDA
第二版、DICOM 複合 SOP クラス、ATSM-CCR、CEN ENV 13606、等）いずれかの書類源として書類を提供します。

2.

この統合プロファイルは、EHR-CR が書類源および書類消費役として、XDS
連携圏内で共有される際、内部情報を保存あるいは管理することを要求して
いません。

3.

書類源と書類登録所を一括すると、EHR-CR は既に保存してあるものを再度保存することなく、保存済のものが同じ方法で利用できる様になります。

4.

HER-CR は書類源および消費役として必要に応じて、自身の現場コードを
XDS 連携圏のコードに対応付ける責任があります。

HER-CR で共有され XDR 登録所で追跡される XDS 書類は、XDS 連携圏の HER-CR で療養を受けた該当患者の縦断的記録を形成します。

図 10.4.1-2: 患者縦断的記録への書類投稿と共有
この共有された臨床情報は、この統合プロファイルでは HER-LR と言われます。
10.4.2 XDS 書類構想
XDS 書類は、文書保管庫に提供される最小単位の情報で、書類登録所の一つのエントリとして登録されるものです。
XDS 書類は、観察結果と医療サービスを含む臨床情報で、情報交換のために、永続性、世話役精神、認証の可能性、全体性の特性を持ちます。これらの特性は HL7 の臨床書類構造（CDA）仕様に定義されています。XDS 書類は、（特定のアプリケーションにより）見読性があることがあります。いずれにせよ、構造、内容とコード化の公表されている標準に合致しなければなりません。IHE はこのような内容標準に依拠した、XDS とあわせて使用________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

92

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

する、内容指向の統合プロファイルを定めるよう意図しています。
XDS 統合プロファイルは、XDS 書類を一単位の情報として管理し、XDS 書類の一部のみを利用する機構を提供しません。書類源、あるいは、書類消費役のみが XDS 文書の内部情報を利用できます。共有のために提出されたとき、XDS 書類は書類消費役に octet stream
として提供されます。書類セット取得（Retrieve Document Set）トランザクションで取得されるときには、提出された octet stream と異なってはなりません。
書類源は、書類登録所に提出される書類の、XDS 書類消費役が問合せ目的で使用する XDS
書類エントリを書類保管庫が作成できるように、メタデータを生成する責任があります。
XDS 書類源は登録した XDS 書類に責任を持ち続けます。提出時に間違いのあった XDS 書
類は XDS 書類源が置き換えねばなりません。XDS 文書構想の詳細な議論は ITI TF-1: 付録
K を参照してください。
XDS 書類は世界規模で一意に同定できねばなりません。正解規模で一意の識別子の定義については ITI TF-2x: 付録 B を参照してください。
10.4.3 書類提出要求
XDS 提出要求は XDS 書類共有の手段です。これは以下の様に伝送されます:

書類源が書類セットの提供と登録（Provide and Register Document Set）ト
ランザクションで書類保管庫に送る



書類保管庫が書類セット登録（Register Document Set）トランザクションで書類登録所に送る。

XDS 提出要求は XDS 書類の適切な登録を確実にする情報要素を含んでいます。これには以下があります:1.

新しく提出される XDS 文書のエントリに対するメタデータ

2.

新しい文書すべてと提出されるフォルダの一覧を含む提出セットと、オプションで、以前提出された XDS 書類の一覧

3.

希望により、含まれる XDS 書類の一覧（新しく提出される書類と以前に提出された書類の両方の一覧）とともに生成されるフォルダ

4.

希望により、（新しく提出される書類と以前に提出された書類の両方）の
XDS 書類の一覧を含む、既存のフォルダへの追加

5.

提出される新しい XDS 書類に対応する 0 個以上の XDS 書類の octet
stream

提出要求が成功すると、新しい XDS 書類、提出セット、提出要求に含まれたフォルダーが、
XDS 連携圏で使用可能になります。提出要求の処理に失敗すると、提出要求、提出セット、と XDS 書類とフォルダは登録されてはなりません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

93

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

10.4.4 提出セットの構想
一個の XDS 提出セットは、提出要求を行う療養提供組織の EHR-CR が提供した、一人の患者に対する療養事例と、関連しています。これは新しい XDS 書類の永続的記録とともに、同じ療養事例に関連する既存（既登録の）の XDS 書類の記録も生成します。これには、新しい XDS フォルダ生成の記録も含まれます。
XDS 提出セットは、それぞれの提出要求ごとに生成されねばなりません。これは一個の書類源と関連し、一個の書類セット提供と登録トランザクション、または、書類セット登録
トランザクションにより伝達されます。
同じ XDS 提出セット内の登録された書類を見つけるため、書類登録所に問合せることができます。
同じ XDS 書類は、最初、提出セットの一部として登録されても、以降の XDS 提出セットから参照できます。これにより、一患者の最新の療養に関連する過去の書類を、より新しい提出セットと関連付けることができます。
XDS は EHR-CR に、書類と提出セットと受診、来訪、療養事例、あるいは種々の業務処理とを関連付ける際の完全な柔軟性をもたらします。
10.4.5 フォルダの構想
XDS フォルダの目的は、種々の理由で数個の XDS 書類をまとめる（たとえば、療養期間、問題、予防接種、毎にまとめる）共同機構を提供すること、および、書類消費役に同じフォルダに置かれたすべての登録エントリを見つける手段を提供すること、にあります。以下の原則がフォルダに適応されます:1.

一個のフォルダは一人の患者の療養に関連する XDS 書類の一セットをま
とめます。

2.

ひとつの任意のフォルダには、一個以上の書類源から書類を登録できます。

3.

フォルダは書類源で生成されるか、XDS 連携圏内で既定のものがあります。

4.

フォルダの内容は、コード値・意味の一覧で保証されます。

5.

文書源は既存のフォルダを、文書登録所に問合せて、あるいは、XDS の
範囲外の方法で、探し出します。

6.

フォルダは、いったん生成されると、書類登録所に永続的に登録されます。

7.

フォルダに既存の書類を置きなおしても、提出文書セットの一部とはな
りません。

8.

XDS のフォルダは入れ子にはできません。

9.

同じ書類が一個以上のフォルダに有ってもかまいません________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

94

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

10. フォルダは世界規模で一意の識別子を持ちます。
10.4.6 提出要求、提出セットとフォルダ使用の実例
以下の一連の図は、2 つの新書類、既存書類への参照、2 つのフォルダの使用を含む提出文
書セットの例を示します。最初の図は、書類登録所の初期の状態で、2 つの書類が提出され、うち一個はフォルダ A と関連付けられています。第 2 の図は、2 つの新文書のうちひとつを既存のフォルダに他方を新しいフォルダ B に入れる、提出要求を示します。

図 10.4.6-1: XDS 登録所への提出業務流れの例
以上の例から、提出セットの内容は以下の図に示されます。提出セットと関連付けられ書類エントリは、提出セットの論理的部分です。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

95

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 10.4.6-2: 提出セットの論理内容
10. 4.7 XDS 登録所のデータモデルと属性
書類源が選択した書類を書類保管庫に置く手段、および、この書類についての情報（メタデータ）を書類登録所のエントリを、XDS 連携圏を管理する登録所に置く手段を、XDS 統
合プロファイルは提供しています。
メタデータという用語は、該当の情報が文書に「ついての」情報であることを意味します。
メタデータの目的は、書類消費役が関心のある臨床書類の所在を見つける、図書館の図書カードカタログで希望の図書を見つける手助けをする様な、統一された機構を可能とすることに有ります。
この節は、メタデータが登録され、このデータに対する XDS 書類登録所の問合せの高次のデータモデルを扱います。次いで、登録使用され、登録のエントリーを絞り込むのに使用される特定の属性を提示します。
10.4.7.1 XDS 書類登録所データモデル
以下の実体（entity）が XDS データ登録モデルに使用されます:
XDS 書類エントリ: XDS 書類の主要な特性を記述するメタデータのセットと実際にその書類が取得できる書類保管庫へのリンクを含む情報の実体（entity）
XDS 書類: 書類保管庫に保存されているバイト長データの一連の流れで、XDS 書類エントリで所在が示されるもの。
XDS フォルダ: １個以上の XDS 書類エントリを、要求に応じて（たとえば療養提供活動、発生事例、療養チーム、診療科、あるいは臨床状態などにより）まとめる論理的な容器のことです。このような体系的構造は種々に使用されます。あるセンターやシステムでは、
健康記録の全体を区分する様に使用されます。他には、起原となった施設あるいはチーム________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

96

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________の EHR のうち法的問題のみをまとめることがあります。フォルダは XDS 文書（あるいは、
EHRCOM の構成）の構造化の手段を与えます。ひとつの同じ XDS 文書は０個以上のフォルダに含まれます。
XDS 提出セット: 書類源が XDS 書類を登録する際には、書類はまさに一個のみの提出セッ
トに含まれねばなりません。XDS 提出セットは 0 個以上の新しい XDS 書類と既存の XDS
書類への参照を含み、提出物の永続的な記録を確保します。
XDS 提出要求: 提出要求はまさに一個の提出セット、0 個以上のフォルダ、XDS 書類の新規あるいは既存フォルダへの割り付け、を含みます。提出要求は書類保管庫により自動的に処理されます（すなわち、提出セットに含まれるか参照されたすべての XDS 書類、および、フォルダとフォルダの参照が、登録されるか全く登録されないかを決めます）これは、
書類消費役にも同様に使用可能とするためです。

図 10.4.7-1: XDS 書類登録所のデータモデル
10.4.7.2 XDS 書類エントリの属性
上記の登録所データモデル内のそれぞれのエントリの特定の属性は数個の標準から取られた文書ヘッダの属性から選択されています。これらには以下が含まれます:

ANSI/HL7 CDA RI-2000



HL7 CDA 第 2 版書類ヘッダ情報定義 2003 年委員会投票）

EHR ENV13606 からの構成属性（案）________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

97

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

もっとも重要な書類を探す使用例の多くを可能とする一次的属性のよく絞り込まれたセットを定義します。

三つのコード（書類クラス、臨床状況、医療機関タイプ）は通常限られた数（10-100 程度）の値を含むコードのセットと予期されており、比較的容易な検索を可能としています。
特定の書類を問合せできる様に、追加の他の問合せ属性もこの統合プロファイルで定義されています。書類レベルではこれには、粒度の細かい書類タイプ（たとえば LOINC 分類）、
キーワードとして使用できる事例コード（Event Code）、書類記述者と関連する施設、補遺の置き換えや種々の変換を管理するための書類間関係、秘匿性コード、言語コード等です。
属性の完全な一覧と定義は ITI TF-3: 4.1 に記されています。
10.4.8 XDS 連携圏の構想
XDS 連携圏は、臨床書類を共有することに同意した、一個の書類登録所の周りに組織され、明確に定義された一組の書類源・書類保管庫・書類消費役から形成される管理組織です。
注: 書類源、書類保管庫、書類消費役は、１個以上の XDS 連携圏に属してよく、同じあるい
は異なった書類を共有できます。
注 : XDS 統 合 プ ロ フ ァ イ ル は XDS 連 携 圏 の 連 合 を 直 接 に は 実 現 可 能 と し ま せ ん が 、異 な る XDS 連 携 圏 に 仕 え る 複 数 の 書 類 登 録 所 の 連 携 は 共 同 体 間 利 用（Cross-Community Access, XCA）プロファイルが扱います。

書類源と書類消費役との間での相互運用を確実にするには、XDS 連携圏でいくつかの基本方針が必要です。重要な技術的基本方針は以下です（XDS 連携圏にに必要な基本方針合意のより広範な一覧は ITI TF-1: 付録 L にあります。
）
1.

受け付ける書類の様式

2.

書類メタデータの提出、提出セット、フィルダ登録に使用される、種々の語彙コード値のセットとコード化方式

3.

書類登録所が使用する患者識別圏（患者 ID 割り付け責任機関）________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

98

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________XDS 連携圏の構想の詳細は、ITI TF-1: 付録 K を参照して下さい。
10.4.9 患者識別情報管理
XDS 統合プロファイルの中心命題は書類の共有であるため、それぞれの文書が該当する患者（PatientId）と正確に関連つけられていることが必須です。
XDS 文書登録所は、患者識別と基本情報の責任担当では有りません。この統合プロファイ
ルでは、XDS 連携圏での患者識別（マスタ患者 ID）の責任担当として患者識別源実行役（Patient Identity Source Actor）を使用します。
注:

この統合プロファイルは、マスタ患者 ID がない状況（すなわち、XDS 連携圏に患者識別源が無い場合）にも容易に拡張できます。このようなオプションでは XDS 書類登録への問合せ
時に、国レベルの患者識別の使用が必要となると思われます）

以下の原理があります:1.

XDS 連携圏の患者識別源が管理する患者識別圏は、患者識別子の源で、XDS 書類登録所が特定の患者に書類を関連付ける（および、融合操作の）際に、使用されます。この患者識別圏は、XDS 連携圏患者識別圏（XDS
Affinity Domain Patient Identification Domain, XAD-Pid Domain）と呼ばれます。

2.

XDS 連携圏患者識別圏（XAD-Pid Domain）に登録されていない患者に関する書類の提出要求は、書類登録所で拒否されねばなりません。

3.

XDS 書類登録はある種の患者情報（たとえば、元施設患者 ID、姓、名、性、誕生日）を監査と書類消費役による確認用に保持します。この統合
プロファイルではこの情報の参照に際しての統合性や更新について一切の前提を置かないので、これらのデータ野3を問合せの照合キーとしてはなりません。

4.

XDS 書類源と書類消費役が別の患者識別圏に属することがあるので、自身の現場患者 ID と登録所の XDA 患者識別圏での患者 ID とを相互参照させる必要があります。このようなシステムでは、IHE 患者識別相互参照（Patient Identifier Cross Referenceing）統合プロファイル（ITI TF-1:
付録 E.3 参照）の使用を推奨します。

5.

XDS 書類登録所は、XDS 連携圏の基本方針に従って書類のメタデータの正確性を保証する責任があります。書類保管庫は、基本方針に合致しない提出要求を拒絶せねばなりません。

3

元の提出要求で提出された書類の誤りを直すため、既存の書類を新しい書類で置き換えることはあり得ます。しかしながらこれは、置き換えられた元の書類だけが廃止され、元のメタデータが指し示す場所は残っているため、メタデータのみを更新する機構では有りません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

99

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

以下の図は、患者識別圏（XAD と言う）と、書類源圏と書類消費役圏（それぞれ、C 圏とD2 圏）とに内部的な相互参照が行われる二つの EHR-CR を有する、XDS 連携圏の例を示します。

図 10.4.9-1: 患者 ID 内部的相互参照を行う二つの EHR-CR を有する XDS 連携圏
10.4.10 書類の生活史
10.4.10.1 書類可用性状態
XDS 書類登録所に含まれるそれぞれの書類は以下のいずれかひとつの可用性状態を持ちま
す。:
承認済み:

患者の療養に使用できます（承認済みが適用可能であれば認証されていると見なされます）
廃止済み:

もはや古いが、まだ問合せと取得が可能です。

XDS 書類可用性は、XDS 書類保管庫と XDS 書類登録所が提出要求を成功裏に処理したとき、承認済みに設定されます。
注: ebXML 登録サービスは「提出済み」状態を定義しますが、原始提出を提供するため一過性に使用されます。この状態を外部から見える様にする意義は有りません。

「承認済み」XDS 書類は、元の書類源の一義的責任で、可能であれば患者看視のもとで、________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

100

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________「廃止済み」に変更できます。
これは XDS 統合プロファイルの保安基本方針の一部であり、XDS 書類保管庫・登録所が自身の所有権を強化することは、統合プロファイルの範囲外です。書類を廃止する理由と責任者は、必須の機能である、XDS 書類登録所査察追跡の一部として追跡さられます。廃止された書類は書類消費役からの問合せに、使用可能であり続けます。廃止された書類エントリのメタデータは、書類状態の”廃止済み”への変更の他は”承認済み”のときと同じ状態で残ります。
承認済み、廃止済みの XDS 書類は削除できます。この変更は、XDS 書類保管庫からの書類
および、書類登録所からの該当する書類エントリ、両者の完全な削除の決定で起こります。
XDS 連携圏は書類削除に関する安全基本方針を定めねばなりません。このような操作を可能とするトランザクションは統合プロファイルでは定義されていません。
XDS 書類の生活史の構想については、ITI TF-1: 付録 K を参照してください。
10.4.10.2 書類の関係
XDS 書類は親書類と以下の 3 つの方法のひとつで関連付けられます。


置換



追補



変換



変換と置換

XDS 書類間の関係は XDS 書類登録所で追跡されます。このような書類のメタデータに含まれる親関係属性は、書類間の関連を示す、コード化された値です。元の書類は親を持たない結果、親 ID と親関係の属性は空です。XDS 書類登録所は登録されていないあるいは廃止された書類と親子関係を持つ提出要求を拒絶します。未登録だが既知の書類との有効な関係を保つため、”文書半券”が XDS では使用可能です。
置換書類は、既存書類の新しい版です。置換書類は新しい書類 ID を持ちます。親 ID 属性には、旧版の XDS 書類に対応する XDS 書類エントリの書類 ID を含み、親関係属性には”RPLC”のコード値を持ちます。旧版の XDS 書類の書類エントリは、可用性属性が”廃止すみ”（deprecated）に変更されます。
追補書類は、既存の書類を参照する別の文書で、既存文書にある観察結果を拡張あるいは変更するものです。これは元の書類を変更しますが、元の書類は患者記録の一部として有効で、”承認済み”状態のままであり、診療に使用可能です。追補 XDS 書類のメタデータには、親 Id（ParentID）に旧版の XDS 書類の版を含み、親関係属性には"APND"コード値を持ちます。
変換書類は、他の書類形式から器械で変換されたものです。たとえば、DICOM SR から変換された CDA 形式、あるいは、レポートから pdf で見読化された書類があります。変換された書類は、親 ID 属性には、旧版の XDS 書類に対応する書類 ID を含み、親関係属性には"XFRM"コード値を持ちます。XDS 連携圏は、変換された書類で元の書類を置き換えるか、________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

101

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

否かの規則を定めることができますが、通常、置き換えません。もし置き換えるときには、追加の親関係属性を”RPLC”に設定します。
10.4.11 書類問合せ
問合せ返答情報は、以下のいずれか一方となります。


登録所対象物値（Registry Object Values、たとえば、XDS Document Entry)の一覧



登録所対象物 UUID 値。これにより、XDS 書類消費役は一致するエントリの長大な一覧を手にして、サブセット単位で取得要求できます。

10.5 実装戦略
XDS 統合プロファイルは、EHR-CR での実行役の異なったまとめ方、および、EHR-LR の異なった設定を反映する、3 つの主要な実装戦略の要求事項を扱います。実装戦略のこのよ
うな広がりは、様々な業務流れや様々な設定に応える必要があることを反映しています。
ある種の環境では複数の実装戦力が併存します。その他の実装も可能です。


実装戦略 1: 書類源に保管庫。一個の情報システムが、書類源と書類保管庫の両方の役を果たし、書類を生成して登録します。



療養のある相が終了したとき、EHR-CR は書類の提出セットを、一体化されている（同じシステム内にある）書類保管庫に保存します。この書類セット（新しく生成された書類と、関連のある以前の書類）は、次いで、書類登録所に登録されます[2]。

XDS 連携圏内の他の書類消費役は患者の療養全相に関連する書類を問合せて見つけます[3]。いずれの書類保管庫からでも選択した書類を取得することを選びます[4]。

図

10.5-1: 書類源に書類保管庫を置く実装戦略

実装戦略 2: 第三者の書類保管庫。EHR-CR は書類保管庫の役を果たしたくな
く、生成した書類を預けることのできる第三者の書類保管庫サービスを使用します。最初に、書類のメタデータと書類のセットをこの書類保管庫に送り________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

102

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

ます[1]。ついで、この保管庫が書類登録所に書類（新しく生成された書類と、関連のある以前の書類）の登録要求を書類登録所に転送します[2]。


他の書類消費役は書類登録所に問合せて、患者の療養全相に関連する書類を見つけます[3]。いずれの書類保管庫からでも選択した書類を取得することを選びます[4]。



図10.5-2: 第三者書類保管庫を置く実装戦略

図10.5-3: 第三者書類保管庫を置く実装戦略

実装戦略 3: 患者直接転院－紹介。書類消費役は一人の患者の療養のある相を完了します。書類消費役は書類セット（新しく生成された書類と、関連のある以前の書類）を、書類保管庫、書類登録所、および EHR-CR 書類消費役を一体化した、書類保管庫[2]（群化実行役）に直接提供して登録[1]します。



この例では、XDS 連携圏は二つの EHR-CR のみを含む狭いものとなります。
しかし同じトランザクション[1]が使われます。この実装戦略では、実行役が使用可能としていても、書類消費薬は、自身の中に書類保管庫と書類登録所の両方を含むため、他のトランザクションを使用しません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

103

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 10.5-4: 書類消費役に書類登録所と保管庫を置く患者直接紹介
EHR-LR の患者による利用は、書類源と書類消費役を実装する、特別な EHR-CR（情報取得門、portal）により可能となります。

10.6 患者識別通信要求事項
ITI トランザクション 8 を患者識別配布（Patient Identity Feed）として使用する時には、患者識別子 PID-3 に書式要求事項を、ITI TF-2a: 3.8 で定めています。特に、PID-3.4 の値、識別子割付責任機関（Assigning Authority）は、第 1 亜要素（namespace ID）、あるいは第 2 および第 3 亜要素（universal ID, universal ID type）で表現すれば、省略できるとしています。この規則はこのプロファイルにも適用されます。:
1.

患者識別源が PID-3.4（Assigning Authority）に値を持たないときは、
a.

PID-3 (Patient Idetifier List)は一個の識別子のみを示す一個のエントリに制限されます。

b.

患者識別源と所流登録所は、この源から来る通信文はすべて一個の識別子割付責任機関をもつと合意せねばなりません。

2.

PID-3.4 が識別子割付責任機関（Assigning Authority）の値を持たない
ときは、
a. 患者識別源は適切に書式化された要素をもつ複数の患者識別子を送信できます。書類登録所は、患者識別子一覧（Patient Identifier List）
から一個の患者識別子を選択し、これ尾を選択した患者の登録に使用する責任があります。リストの最初を選ぶとは決まっていません。
b. ITI TF-2a: 3.8 に指定された様に、PID-3.4（Assigning Authority）は、
第 1 亜要素（namespace ID）、あるいは第２および第３亜要素（universal ID, universal ID type）で表現できます。書類保管庫はこの両方の方法を受け付けねばならず、これらは同等と見なされねばなりません。

ITI トランザクション 44 を使用するときは、識別子割付責任機関（Assigning Authority）
が必須です。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

104

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________ITI トランザクション 18, 41, 42 を使用するときは、Patient ID は文字列（ストリング）
として扱われますが、典型的な HL7 の解読方法とは異なった方法で解読されます。これらのトランザクションでの Patient ID の要求事項を参照してください。
書類登録所は、ITI-8、
ITI-44 では上記の様に与えられる患者識別、このプロファイルのトランザクションで与えられる PID との対応付けをしなければならないでしょう。
XDS.b 実装は、Patient Identity Feed (ITI TF-2a: 3.8)、あるいは、Patient Identity Feed
HLv3(ITI TF-2b: 3.44)のいずれか、あるいは、両者を使用可能としなければなりません。
XDS.b が実装する HL7 の版と、Patient Identity Feed の HL7 の版とは、相互運用性確保のため、一個の連携圏あるいは共同体の中では、一致せねばなＲないことに注意してください。両者が混在する環境では、Patient Identity Feed (ITI TF-2a: 3.8)と Patient Identity
Feed HLv3(ITI TF-2b: 3.44)の間での通訳が、ブリッジあるいはインターフェースで必要となります。

10.7 安全の考慮
XDS 連携圏内のあらゆる療養提供施設の安全とプライバシ基本方針の協調は困難なことがあります。保安処置、目標、監査、記録保持などについての合意が必要です。これは他の施設基本方針、たとえば、人的資源処理、の変更をもたらし得ます。XDS 連携圏の参加施
設は、自己が公表したデータを他の参加施設が利用することに一定程度信頼を寄せています。制御のレベルは、基本方針や IHE が提供する他の安全、プライバシ保護アプリケーシ
ョンに依存します。基本方針、手順、活動を常時維持することを可能とする常に存在する
密接な相互関係が必要です。法律の変更が有ったときは、グループ全体で関連する基本方
針が適合されねばなりません。参加施設の会社が変更されると、基本方針に影響します。
安全事例は一個の群として管理されねばなりません。これは長期にわたる活動であり、一回限りの事例では有りません。
特に問題の有る領域には以下が考えられます。


利用の認証と変更の基本方針。

利用方針には施設差があり、矛盾は解決されねばな

りません。XDS 連携圏の基本方針は、新しい基本方針の導入を要します。たとえば、雇用状態の変更（採用と解雇）は直ちに連携圏内の他の施設へ速やかに通知されねばなりません（ATNA, XUA を参照）。


プライバシ制限の変更（たとえば離婚）は施設内への通知のみならず、連携圏全体への通知を要します（BPPC 参照）。



監査追跡と利用記録保存はしばしば微妙な施設内活動ですが、XDS 連携圏では全体で適切に協働せねばなりません。
（ATNA と 10.8.1 節を参照）



法令の変更は、個々の施設の基本方針の変更のみならず XDS 連携圏契約、基本方針、操作手順にも反映されねばなりません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

105

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________



患者識別管理（PIX/PDQ/XCPD 参照）



認証された書類消費役、あるいは、PHR の様なアプリケーションをもつ書類源から患者が、情報を利用する可能性があります。



個人健康情報（PHI）の境界を越えた通信は、しばしば法的、規制上の問題を生じます。

ITI TF-2x: 付録 K には、XDS 連携圏内の施設が協働せねばならないこれらの脅威、目的、
基本方針、軽減措置をより詳細に記述しています。
XDS 統合プロファイルは、このような保安やプライバシー方針を、２つの理由から提供しません。ひとつは、この様な基本方針には、法的規制枠、医療施設の類型に依存する基本方針には数多くの解決法が考えられるので、XDS には大きな柔軟性が要求されるためです。
この連携圏での決定は XDS 実行役の実装に影響を及ぼしますが、この影響は最小限のものと予期されます。
10.7.1 基本保安処理への ATNA の使用
XDS プロファイルではすべての実行役が IHE 監査追跡と安全拠点（ATNA）と一括化されることを要求しています。このような ATNA プロファイルの XDS 連携圏における使用は、中央化された XDS 連携圏監査記録保管庫を必要としません。
XDS と ATNA をともに使用するときは、XDS 連携圏参加施設のそれぞれに監査と保安機構が働いていることを要します。ITI TF-2x: 付録 K を参照してください。
図 3.14.5.1-2 に示されるごとく、実行役のそれぞれは異なる安全圏の一員であることがしばしばです。異なる安全圏の間でのデータ転送は、一個の安全圏内でのデータ転送とは異なった保護策が必要となることがあります。暗号の使用やその他の安全策の使用は、動員されている安全圏の基本方針に依存します。
一個の安全圏内のデータ転送には、必要ない場合には暗号化を用いない選択も可能ですので、オンラインの安全策の設定が変更可能であるように推奨します。証明書管理と交換は
XDS 連携圏の事業関係の一部として定められており、他の IHE 統合プロファイルは今のところ定められていません。ITI TF-1: 付録 L を参照してください。
それぞれのトランザクションは、それを記述し得る監査記録を結果として生み出します。
それぞれの安全圏はそれ自身の監査サーバを有して圏内の実行役の記録を捕捉します。
XDS 連携圏内の他施設からの監査記録利用は、XDS 連携圏の事業関係条件で管理、制御されます。利用のそれぞれには、自動化された IHE トランザクションは有りません。
通常の XDS 活動に伴い（IHE ATNA 統合プロファイルを参照して）生成されねばならない
監査記録は、それぞれのトランザクションの「安全考慮」の節に定められています。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

106

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 10.7-1: 安全圏間関係の例
安全とプライバシは IHE-BPPC, IHE-XUA の適用によりさらに高度に処理することができます。これらのプロファイルの影響と使用法を参照してください。

10.8 意図的に空白________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

107

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

11 職員録（Personnel White Pages, PWP）
職員録統合プロファイルは施設内の職員の索引情報を他の職員が利用できる様にします。
この情報は医療機関内での、臨床用、あるいは非臨床用のアプリケーションの間で広い適用があります。情報は以下の様に使用されます:
1. 臨床業務流れを強化しますa. 連絡先b. 電話番号c. 電子メールアドレス
2. 使用者インターフェースを強化します
a. 表示する名前
b. 職位
この職員録プロファイルは、施設使用者認証（EUA）プロファイルで提供される使用者識別（User Identities, user@relm）についての索引情報を見つける手段を定めます。この統合プロファイルは利用制御や監査を前提としますが、定めはしません。PWP 統合プロファ
イルは医療機関内のみでの利用を意図しています。医療機関間での PWP 共有を可能とする
拡張は、可能ですがこの統合プロファイルでは完全には扱いません。PWP は、デジタル証
明書、暗号化、デジタル署名、医療資格証明書、任務を含む、IHE 手引きの最初の一歩です。
この索引は医療機関運用を超える使用例（たとえば、労務管理）を可能としませんが、他の使用例との適切に設計された重複を禁止するものではありません。この統合プロファイ
ルは、患者あるいは、医療施設の労力でない個人に使用することを意図していません。

11.1 実行役・トランザクション
図 11.1-1 に PWP 統合プロファイルに直接含まれる実行役と、実行役間の関連するトランザクションを示します。EUA プロファイルへの参加のため PWP に間接的に含まれる他の実行役は必ずしも含まれません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

108

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 11.1-1: 職員録統合プロファイル実行役図
表 11.1-1 に、PWP に直接含まれる実行役のそれぞれのトランザクションを示します。この統合プロファイルが使用可能であると主張するには、実装品は必須のトランザクション（”R”と表記）を実行せねばなりません。”O”と表記されたトランザクションはオプション
です。この統合プロファイルで定められ、実装品が使用可能にできるオプションのの完全な一覧は、ITI TF-1: 11.2 にあります。
表 11.1-1: PWP 統合プロファイル－実行役とトランザクション

11.2 PWP 統合プロファイルオプション
この統合プロファイルに選択可能なオプションを、適応される実行役とともに、表 11.1-1に示します。オプションの間に依存があれば、注記されます。
表 11.2-1: PWP 統合プロファイル－実行役とオプション

11.3 PWP 統合プロファイル処理流れ
職員録(PWP)統合プロファイルは以下の使用例を処理します。


職員録消費役として働く収集装置を臨床業務の使用者が認証を受け使用します。臨床
アプリケーションは[ITI-23]を使用して PWP 索引を見つけます。次いで、臨床アプリ
ケーションは、使用者名（username）を使用して PWP 索引に問合せ、使用者の姓、名、ミドルネームをふくむ完全な氏名を表示します。ヨーロッパおよびアジアの命名規則を使用可能とする情報データ野が用意されています

臨床業務の使用者が臨床データを取得します。アプリケーションは[ITI-24]を使用してPWP 索引に使用者の基本情報を問合せ、データ記録に施設での使用者識別を埋め込みます。



使用者はこのデータ記録を電子メールで同僚に送信する必要があります。アプリケー
ションは、使用者が送信先を PWP 索引で検索できるようにし[ITI-24]、送信先の電子
メールアドレスを選択します。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

109

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

使用者は既存の臨床レポートを閲覧してレポートに記入された名前の頭文字を見つけます。使用者システムはレポートの名前の頭文字を PWP 索引に問合せ（[ITI-24]）、表
示可能な名前を表示します。
図 11.2-1: PWP プロファイルでの基本的処理流れ

12 この節は書類可用性通知（Notification of Document Availability, NAV）のため予約されています。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

110

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

13 施設間使用者断定（XUA）統合プロファイル
施設間使用者断定（Cross-Enterprise User Assewrtion, XUA）統合プロファイルは、施設の境界を越えるトランザクションにおいて、認証された指導的主体（使用者、アプリケー
ション、システム、など）についての情報取得要求を通信する手段を提供します。施設間
トランザクションの説明責任を果たすため、受信者が利用許可を行い適切な監査事例を生成できるような方法で、要求者を同定する必要があります。XUA プロファイルは、自施設の独自の使用者認証方法でつくる使用者索引を持つ施設でも、認証を第３者にゆだねる施
設でも、多くの解決法を使用可能とします。
IHE が定めた施設の境界を越えるトランザクションも、ITI TF-2x: 付録 V に基づくウェッブサービスもあります。認証された使用者の同定に使う、既存の IHE プロファイル（IHE
Enterprise User Authentication, EUA）は、施設間トランザクションで機能する様に意図されていません。施設間の環境では、トランザクションは、それぞれが独立した使用者索引（PWP）を持つ施設間で起こる方が多いと思われます。この種の要求事項は識別連合標
準（Identity Federation Standard）の焦点です。識別連合は最近、安全産業やプラットフ
ォーム産業から多くの関心を集めています。識別連合は使用者索引のタイプに関知しません；中央化した使用者索引を許しますが、使用者索引のもっと強力な連合も使用可能とします。識別連合は以下を可能とします:

すべての使用者を１つの割り付け責任機関に提供するよう委託する国（たとえば、フランス）で、すべての使用者認証請求を共通して行うサービスを提供します。



中央化された使用者索引



自身で使用者を管理する病院や診療所が協働するネットワークをつぐむ１つの地域圏



分散した使用者索引



自分の好みの個人識別供給者（たとえば、IPS, 電子メールプロバイダ）を使用したい
患者

医療に関係しない使用者のみの使用者索引



写真と名前を印刷した個人識別バッジを発行したり、RFID カードを建物への立ち入りに使用したり、強力な認証にスマートカードを使用する病院



使用者を認証する方法の取得（たとえば、スマートカードの様な強力な使用者認証）

１０人ほどの使用者からなる田舎の小さい診療所

小さな規模のシステム（たとえば、売店[のような小規模システムの]使用者、単純なパスワードを使用するシステム）



情報を要求した使用者に固有の監査記録を要求する外来診療所で行われた、検査の結果を閲覧する総合診療医



監査を記録する目的で使用者識別情報を得たいサービス提供者



予定された処理を自動実行するシステムで、医師の代わりに使用可能な書類を予め取________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

111

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

り寄せ、患者到着時に必要な書類を医師に提示する場合


XUA プロファイルは、ウェッブサービス安全、SAML 2.0 トークンプロファイル、および W3C と OASIS からの種々のプロファイルに影響を与えます。これにより、医療以外の共同体で得られた多くの経験から利益を得られます。このプロファイルは医療で SAML を使用し始めた世界中のプログラムでの経験を使って影響を及ぼします。

13.1 使用例
XUA プロファイルは、たとえば、二つの信託圏が異なった技術・手順・役割モデルなどで運用されるような複雑な環境でも使用可能です。これらは XDS 連携圏内でアーチ覆型信頼関係（overarching trust relationship、ITI TF-2x: 付録 L）基本方針のもとで協働しており、上記のような相違は理にかなう様に処理可能であることがわかります。XDS トランザ
クションは、たとえば医師の個人診療から複数施設をもつ病院の間でデ－タを交換する場
合の様に、ひとつの主体から他の主体に制御を移しています。このような場合、すべての施設が同じ利用制限モデル（組織の役割、機能的役割、業務流れ、許可、など）に合意す
るとは思いにくいです。主体の間ですべて同じ利用制限が必要なわけではありませが、基本方針のレベルでは処理の規則を合意することができます。これにより、XUA は安全監査
記録には有益ですが、利用制限には有用性が劣ることがわかります。
以下は XUA に提案されている使用例の一覧です。
使用例のいくつかは標準の欠如あるいは、
適切な解決法のガイドラインの欠如のため、実現していません。
1.

すべての使用者を１つの割付け責任機関圏に入れ、すべての使用者認証を行う国（たとえば、ドイツ）2.

中央化された使用者索引のサポート

3.

自身で使用者を管理する多数の競合病院や診療所をつむぐ地域

4.

分散した使用者索引のサポート

5.

自分の電子メールアドレス供給者を認証責任機関としたい患者が PHR 様のアプリケー
ションを使用して、XDS 連携圏内の自己の情報を利用したい患者

6.

医療に関係しない使用者のみの使用者索引のサポート

7.

写真と名前を印刷した個人識別バッジを発行したり、RFID カードを建物への立ち入りに使用したり、強力な認証にスマートカードを使用する病院

8.

使用者を認証する方法の取得（たとえば、スマートカードの様な強力な使用者認証）
のサポート

9.

１０人ほどの使用者からなる田舎の小さい診療所

10. 小さな規模のシステム（たとえば、売店[のような小規模システムの]使用者、単純なパスワードを使用するシステム）のサポート
11. 情報を要求した使用者に固有の監査記録を要求する外来診療所で行われた、検査の結________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

112

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

果を閲覧する総合診療医
12. 監査を記録する目的で使用者識別情報を得たいサービス提供者のサポート
13. 予定された処理に基づくシステムで、使用可能な書類を予め取り寄せ、患者到着時に必要な書類を医師に提示する場合
14. 人が開始するのでない業務を実行するシステムを使用者として識別することのサポー
ト
15. サービス提供者が使用者の認証が特定の保証レベルに達しているか知りたい場合の、登録所あるいは保管庫を使用する使用者。これはシステムを信頼しない場合と異なり、要求者が異なったレベルの認証が可能であることの認知です。たとえば、身近のカードによる認証も、PIN 付のスマートカードによる認証も可能とする場合です。分散された利用を制限する ATNA による利用制限とは異なります。
16. 識別の保証程度をもつ、使用者識別が必要です。
17. 緊急用のデータセットに特化した XDS 連携圏。この例では、XDS 消費役への情報の転送は完全な制御の死活問題ではなく、信頼できる源で認証された使用者である限り、どのようなシステムからの要求も受け付けます。信頼できる源とは、初期応答者用の特別の識別供給役です（RSA Pilot を見てください）。
18. この場合には、信頼できる識別供給役との適切なリンクをもつ使用者識別のみが必要です。特定の属性は必要ありません。
19. 監査記録に使用者識別と役割を記入するため使用者識別と役割を知りたいと思う場合の、識別された臨床役割を持つ登録所使用者。
20. 機能役割を命名された語彙として含むことのサポート
21. データ項目としての使用者の役割（患者）22. 使用者の識別または・および機能的役割にもとづいて利用制限を強化したいサービス
提供者
23. サービス提供役が、使用者および・または機能的役割に適用する、非特異的なある種の規則にもとづいて、利用制限を強化することのサポート
11. 認証提供者を利用できないため識別できない個人による書類の利用

13.2 XUA の開発
大多数の使用例（1-11 項）は認証された識別についての情報取得要求に依拠しており、これは、SAML 2.0 識別断定で可能です。これは OASIS 作成の成熟した標準です。XUA プ
ロファイルは ITI TF-2x: 付録 V に従うウェッブサービストランザクションです。施設間使用者認証が必要なときは、ウェッブサービストランザクションは、識別認証を含む SAML
2.0 トークンを持つウェッブサービス安全ヘッダを追加して使用すると、XUA は定めています。あらゆる IHE プロファイルと同様、アプリケーションは主導的主体（使用者）識別を与える他の方法の使用を禁止されているわけでなく、相互運用性がある種の基本方針で________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

113

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

確実にできるようにしています。
すべての使用例でのきわめて明らかな要求は、安全監査記録の中で使用者識別を記録することです。XUA は監査事項を定めません。安全監査事例の記録の必要は群形成されたトラ
ンザクション（登録所保存問合せ、書類セット取得）で行います。XUA は ATNA 監査通信
文のなかで識別断定（Ideitity Assertion）を如何に参照するかを定めています。
主導的主体（使用者）を認証する方法と X サービス使用者実行役（たとえば XDS.b 書類消費役）が識別断定（Ideitity Assertion）を取得するため使用する方法は、このプロファイ
ルの範囲外です。
使用例で必要と思われる主導的主体（使用者）の属性があります: 医師、患者、守衛、緊急利用、です。識別断定は主導的主体（使用者）についての属性を含むことができます。現時点では、どの標準がこのような属性と値を識別するのに使用するか明確ではなりません
ので、現場の語彙、あるいは現場での語彙翻訳を定める個別の実装に任されています。
X サービス使用者（たとえば XDS.b 書類消費役）実行役が識別断定（Ideitity Assertion）の内容を定めることはこのプロファイルの範囲外です。これは、SAML メタデータとWS-Policy で可能となるでしょう。
将来、HL7 と DICOM にこの解決法を広げることは、将来可能となります。

13.4 実行役・トランザクション
図 13.4-1 に患者入院管理（PAM）統合プロファイルに直接含まれる実行役（太字、実線の四角）と、実行役間の関連するトランザクション（太字と実線）を示します。図は相互作用（灰色の点線）を含む補助的な実行役（点線で灰色の四角）も示します。群形成する実行役は X サービス使用役と X サ－ビス提供役との間の点線で示されます。

図 13.4-1: 施設間使用者認証統合プロファイル実行役図
表 13.4-1 に、XUA 統合プロファイルに直接含まれる実行役のそれぞれのトランザクション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

114

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

を示します。補助的な実行役と関連するトランザクションは、内部的な共有サービスから識別管理のための基盤にわたる、種々の技術やシステム設定により可能となる化も知れません。
この統合プロファイルが使用可能であると主張するには、実装品は必須のトランザクショ
ン（”R”と表記）を実行せねばなりません。”O”と表記されたトランザクションはオプションです。この統合プロファイルで定められ、実装品が使用可能にできるオプションのの完全な一覧は、ITI TF-1: 13.5 にあります。
表13.4-1: XUA－実行役とトランザクション

13.5 オプション
この統合プロファイルに選択可能なオプションを、適応される実行役とともに、表 13.5-1に示します。オプションの間に依存があれば、注記されます。
表 13.5-1 XUA－実行役とオプション

13.6 群形成
13.6.1 監査追跡拠点認証 (ATNA)X 識別断定は貴重であり、秘匿性リスクから防御されねばなりません。ある種のプロファイ
ル（たとえば XDS）では、必須のつきものとして ATNA 安全拠点、あるいは、安全アプリ
ケーションとの群形成が既にあります。この群形成によりネットワークトランザクション
は相互に、認証され暗号化された TLS、あるいは同等物の使用を強制されます。XUA に影響されて、X 使用者断定をある種の秘匿性と統合性のリスクからの防御を可能とします。
ATNA 安全拠点または安全アプリケーションと群形成が必須でないと、X 使用者断定提供を保護する機構が必要となります。
ITI TF-2b: 30.40.4.2 に ATNA 監査通信文での X 使用者断定を表すコード化規則があります。
13.6.2 施設間書類共有（Cross-Enterprise Document Sharing, XDS）
XDS.b 書類消費役が X サービス使用者アンカーと群形成されたとき、XDS.b 書類消費役は
X 使用者断定提供トランザクションのすべての要求事項に適合せねばなりません。書類消費役は、XDS.b 書類登録所あるいは XDS.b 書類保管庫に向けた XUA 断定を取得します。使________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

115

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

用する方法は、内部的手段、SAML 2.0 Core プロトコル、WS-Trust、あるいはその他の縦断です。
XDS.b 書類登録所と XDS.b 書類保管庫が X サービス提供役と群形成されたときは、 X 使
用者断定提供トランザクションのすべての要求事項に適合せねばなりません。XUA プロフ
ァイルは如何に断定が使用可能か（たとえば、無視、利用制限、など）について制限を設
けません
13.6.3 施設使用者認証（Enterprose User Authentication, EUA）
EUA と XUA 実行役を群形成するアプリケーションは、安全トークンサービス(STS)から X
使 用 者 断 定 を 取 得 す る た め WS-Trust を 使 用 で き ま す 。 こ の 場 合 、 SAML 断 定 のAuthnContextClassRef 要素は以下で無ければなりません:
urn: oasis: names: tc: SAML: 2.0: ac: classes: Keroberos
この一個の安全トークン形式から他の形式への変換は、WS-Trust 標準に記述されており、これ以上は IHE では特性付けされません。
13.6.4 ITI TF-2x: 付録Ｖに影響するウエッブサービストランザクション
ITI TF-2x: 付録Ｖに従いウエッブサービスを使用するいかなる実行役も、適切な XUA 実
行役と群形成できます。X サービス使用者実行役と群形成された実行役と要求実行役は提供役 X 使用者断定トランザクションのすべての要求事項に適合せねばなりません。使用できる方法には、内部的手段、SAML 2.0 Core プロトコル、WS-Trust、その他の手段です。X
サービス提供役と群形成された実行役は提供役 X 使用者断定トランザクションのすべての要求事項に適合せねばなりません。XUA プロファイルは如何に断定が使用可能か（たとえば、無視、利用制限、など）について制限を設けません________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

116

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

13.7 処理流れ

図 13.6-1: 施設間使用者断定処理流れ
上記の流れ図には、このプロファイルで定める以上の実行役が示されています。この図はIHE-EUA、IHE-PWP, SAML 識別供給役と群形成した場合を示します。使用者認証提供役、使用者索引提供役、X 断定供給役はここでは特徴付けられていませんが、XUA トランザク
ションに内容を与えるものです。

13.8 安全の考慮
XUA のリスク評価には、資産、脅威、緩和があげられます。XUA 実行役と群形成された実行役（たとえば、登録所保存問合せ、書類セット取得）のリスク評価は XUA プロファイルの範囲外です。これらのトランザクションにういては安全考慮を見てください。リスクの完全なデータは IHE に保存され、IHE から使用可能です。リスク評価の目的は XUA 実行
役を実装する際に考慮すべきリスクを製造会社や医療提供者に知らせることです。一般的なリスクと脅威は ITI TF-1: 付録 L をっみてください。製造者には、多くのリスクは IHE
統合プロファイルでは緩和できず、緩和の責任は製造者、時に、連携圏、個々の機関、実装者、に移されることを助言します。このような場合には、IHE は以下の節の使用を通して関連する団体に通知して責任を果たします。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

117

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

14 患者入院管理（PAM）統合プロファイル
14.1 患者入院管理使用例
患者入院管理（Patient Administration Mgamenet, PAM）統合プロファイルは、患者識別、受診情報、および、急性期診療での患者移動を支える通信文の交換にもとづくトランザク
ションを定めています。これらは以下の使用例で表せます。

14.2 患者識別管理使用例
太陽病院から入力された患者情報に基づき、患者 John Smith を新規登録すると患者特録ア
プリケーションが決めます。この時点では、John Smith（訳者注: 身元不明患者に付ける仮の名前）に関する限られた情報特性しか使用可能でありません。誕生日、住所、家電話
番号、は不明です。患者登録アプリケーションは患者識別を生成し、”Patient Creation ”
通信文を既知の患者個人情報特性セットを下流のアプリケーションへ送ります。
翌日、John Smith の詳細な個人情報が使用できる様になります。患者登録アプリケーショ
ンは患者識別記録を更新し、”Patient Update”通信文を送ります。
一週間後、月イメージングセンターからの入力に基づいて、患者登録アプリケーションはJohn Doe の仮患者識別を生成します。仮の患者識別の整合性確保を経て、John Doe（訳者
注: 身元不明死者に付ける仮の名前）の患者基本情報を、John Smith（の新しい事例に）更新し、割り付けられた元の仮患者識別を永久患者識別に変更します。
検視のあと、これら２つの John Smith の識別は同一人に対するものであることが判明します。操作者は２個目の患者識別を、以前に John Smith に割り付けられた患者識別と融合すると決めます。”Patient Merge”が下流へ通信されます。
14.2.1 患者受診情報管理使用例
患者 Alan Alpha は年一回の検診のため診療所に到着します。患者登録システムは患者登録
情報を現場の補助システムと関連病院の ADT システムに送ります。
Alan Alpha の検診で深刻な状態が明らかとなり、緊急入院が勧められます。Alan Alphaは入院のため関連病院に紹介されます。患者は仮入院して関連する検査を受けます。検査で深刻な状態が確認され、病院の ICU に入院します。ICU 入院中に患者の保険が確認され、更新情報が病院 ADT システムから複数の補助システムへ送られます。
ICU 一日いて、Alan Alpha の状態は改善し、通常の病床へ転送されます。転送の記録を付
ける看護師が誤りを犯し、間違った病室と病床を送信します。誤りの発見後に、転送は取り消され、正しい転送が記録されます。患者は回復し、退院間近となります。病院の手順にしたがい、患者は経過観察の検査を受けるため外来ユニットへ転送されます。患者は病院の外来患者登録システムに登録されます。
Alan Alpha の外来での受診は完了しました。検査結果が満足すべきものだったので、患者________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

118

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

は退院し、外来患者登録システムからも退出します。
この使用例では、二つの患者受診管理システム（病院 ADT と病院外来患者登録システム）が同僚の様に協働します。
14.2.2 実行役・トランザクション
図 14.1-1 に患者入院管理（PAM）統合プロファイルに直接含まれる実行役と、実行役間の関連するトランザクションを示します。他の IHE 統合プロファイルへの参加のため PAMに間接的に含まれる可能性のある他の実行役、たとえば、放射線予定業務流れ、患者識別
相互参照、などは必ずしも含まれません。

図 14.1-1: 患者入院管理統合プロファイル実行役図
表 14.1-1 に、PAM に直接含まれる実行役のそれぞれのトランザクションを示します。この統合プロファイルが使用可能であると主張するには、実装品は必須のトランザクション（”R”と表記）を実行せねばなりません。”O”と表記されたトランザクションはオプション
です。この統合プロファイルで定められ、実装品が使用可能にできるオプションのの完全な一覧は、表 14.2-1 にあります。
表14.2-1: 患者入院管理－実行役とトランザクション

14.3 患者入院管理統合プロファイルオプション
この統合プロファイルに選択可能なオプションを、適応される実行役とともに、表 14.3-1に示します。オプションの間に依存があれば、注記されます。
表 14.3-1: 患者入院管理－実行役とオプション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

119

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

注１: IHE 国別拡張では、Merge と Link の少なくともいずれか一方を選ばねばならず、さらに、相互運用性確保のため、実装品ではその領域での患者基本情報供給役と患者基本情報消費役の両方に同じオプションを必須とせねばなりません。
注 ２ : 中 断 事 例 管 理 （ Pending Event Management ） オ プ シ ョ ン は 、 外 来 ・ 入 院 患 者 受 診 管 理（Inpatient/Outpatient Encounter Management）オプションに依存します。

PAM 統合プロファイルでは患者基本情報、患者受診情報、を広い環境で交換することを可能にします。特に、この統合プロファイルでは急性期医療と外来診療施設の両方を扱います。個別の一個の特定環境で全てのオプションが必要であることはないと思われます。
一方で、外来診療施設では、ITI-30 トランザクションを使用する患者基本情報供給役と患者基本情報消費役の一対しか必要としない可能性があります。他方、病院患者入院管理シ
ステムとその複数の補助システム（検査部、放射線、心臓病、など）は、ITI-31 トランザ
クションを使用する患者受診情報供給役と患者受診情報消費役の実行の一対と入院患者・
外来患者管理オプションとで完全に満足する可能性があります。
従って、この統合プロファイルを使用する機関で最初に行わねばならない決定は、適切な実行役と必要を満たすための適切なオプションのセットを選択し、選択されたオプション
がトランザクションの両側で実行可能であると確認することです。
さらに、PAM 統合プロファイルは、IT 基盤プロファイルとして、孤立して使用できません。
むしろこのプロファイルの実行役とトランザクションは他領域の統合プロファイル（放射線、心臓病、検査部、あるいは、施設間書類共有）に影響されます。ここでもまた、自らの領域で PAM に影響を与えたいと思う IHE 委員会で最初に行わねばならない決定は、適切なオプションのセットを選択し、その領域内で一貫した使用を確保することです。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

120

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

この様に、IH 領域別テクニカルフレームワークを作る際、あるいは採用する際には、PAM
統合プロファイルのオプションの元々の数を減らす制限を行うと思われます。
しかしながら、供給側のアプリケーションが実装するオプションを消費側アプリケーショ
ンが実行可能としない状況に対応するため、消費側アプリケーションが、使用可能でない
旨の拒否の通信文を出さねばならないと、PAM 統合プロファイルは述べねばなりません（ITI TF-2x: C2.3 参照）。
14.3.1 融合オプション（Merge Option）
融合オプションは患者識別を融合する際に必要な情報交換を規定します。
14.3.2 Link/Unlink オプション（Link/Unlink Option）
Link/Unlink オプションは、それぞれ、患者識別を連結、あるいは、連結解除する際に必要な情報交換を規定します。
14.3.3 入・外来患者受診管理オプション（Inpatient/Outpatient Encounter Management
Option）
入院患者・外来患者受診管理オプションは、患者仮入院や、施設内の一カ所から別の場所への転送、および、患者階層の変更に、必要な情報交換を規定して基本的患者受診管理機
能を拡張します。
14.3.4 中断事例管理オプション（Pending Event Management Option）
中断事例管理オプションは、たとえば、入院、転送、退院のような中断事例に必要な情報交換を規定して、基本的患者受診管理機能を拡張します。
14.3.5 高度受診管理オプション（Advanced Encounter Management Option）
高度受診管理オプションは、患者の外泊、受診中の受持医交替、異なった患者識別間での会計口座の移動、などの処理に必要な通信文のセットを規定して、基本的患者受診管理機
能を拡張します。
14.3.6 一時的患者転送追跡オプション（Temporary Patient Transfer Tracking Option）
一時的患者転送追跡オプションは、療養施設からの一時的外出と施設への帰院の追跡に必要な情報交換を規定します。
14.3.7 移動履歴オプション（Historic Movement Option）
移動履歴オプションは基本的患者受診管理機能を、以下のオプションと同様、拡張します。
 入・外来患者受診管理オプション
 中断事例管理オプション
 高度受診管理オプション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

121

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

移動履歴オプションは情報交換のもとで伝達されたあらゆる移動を一意に同定する手段を与えます。これにより、最初に報告されたよりも後刻で、この事例を更新することを可能にします。

14.4 患者入院管理統合プロファイル実行役の群形成
14.4.1 患者受診供給役の実行役群形成
患者識別と基本情報を取得して ITI-31 トランザクションで患者受診通信文機能を発揮するには、患者受診供給役は、図 14.4-1 に示す様に、患者基本情報供給役あるいは患者基情報
消費役と群を形成せねばなりません。

図 14.4-1: 患者受診供給役の群形成の要求事項
一方、ITI-31 トランザクションは、患者受診情報供給役が患者受診情報と患者識別および基本情報との両者を（受診情報の一環として）患者受診情報消費役に送信するとの意味では、自己完結的です。さらに、ITI-31 トランザクションでは、患者受診情報供給役が患者受診情報消費役に、受診情報の一環として 患者識別情報の更新と融合を含んだ患者識別情報維持の通信文を送ることができます。者受診情報消費役に必要な群形成はありません。
14.4.2 ほかの IHE 実行役の群形成
PAM 統合プロファイルは一個または多くの医療機関で、複数の臨床状況で種々の臨床的機能を可能にするために、患者識別情報、基本情報、受診情報を配布する基盤を与えます。
PAM の実行役はほかの IHE 統合プロファイルと群形成できます。
可能性のあるものは、この統合プロファイルの患者基本情報供給役または、患者基本情報
消費役と、PDQ 統合プロファイルの患者基本情報供給役との群形成で、患者基本情報問合せトランザクションで定める問合せを、PAM 統合プロファイルで管理される同じ情報セットに行うことを追加で可能にします。
さらに、PDQ 統合プロファイルの患者基本情報供給役は、この統合プロファイルの患者受________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

122

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

診情報供給役との群形成が可能です。患者受診情報供給役の必須の群形成（ITI TF-1: 14.4.1
参照）により、患者基本情報問合せトランザクションと患者基本情報・受診情報の両者で定める問合せを、PAM 統合プロファイルで管理される同じ患者情報と受診情報セットに行うことを可能にします。
これらは、PAM 実行役とほかの IHE 実行役との可能な群形成の例です。ほかの多くの群形
成の可能性も（価値を加えるかプロファイルの構造を単純化するかして）有用と思われます。たとえば、放射線予定業務流れでは、オーダ発行役とオーダ実行役は患者受診情報消費役と群形成できます。

14.5 患者入院管理処理流れ
14.5.1 患者識別管理
患者識別管理は以下の処理流れを組み込みます。これは ITI TF-1: 14.1.1 の使用例を洗練したものです。
14.5.1.1 患者識別生成と維持

患者生成（Create Patient） 患者基本情報供給役が、太陽病院からの情報の入力にもとづいて新患 John Smith を生成するよう記述します。この時点では、John Smith（訳者注: 身元不明患者に付ける代表的な仮の名前）に関する限られた情報特性しか使用可
能でありません。誕生日、住所、家電話番号、は不明です。患者基本情報供給役は患者識別を生成し、”Patient Creation ”通信文で既知の患者個人情報特性セットを患者基
本情報消費役へ送ります。



患者基本情報更新（Update Patient Demographics） 翌日、John Smith の詳細な個
人情報が使用できる様になります。患者基本情報供給役は患者識別記録を更新し、誕
生日、住所、家電話番号を含む”Patient Update”通信文を送ります。



仮患者生成（Create Temporary Patient） 一週間後、月イメージングセンターからの入力に基づいて、患者基本情報供給役患は John Doe の仮患者識別を生成します。



患 者 更 新 と 識 別 子 変 更 （ Update Patient Demographics and Change Patient
Identifiers） 仮の患者識別の整合性確保を経て、患者基本情報供給役は John Doe（訳者注: 身元不明死者に付ける代表的な仮の名前）の患者基本情報を、John Smith（の新しい事例に）更新し、割り付けられた元の仮患者識別を永久患者識別に変更します。



患者識別の融合（Merge Patient Identifiers） 検視のあと、患者基本情報供給役にある２つの John Smith の識別は同一の実在人に対するものであることが判明します。操
作者は２個目の患者識別を、以前に John Smith に割り付けられた患者識別と融合すると決めます。患者基本情報供給役は”Patient Merge”を患者基本情報消費役に通信します。

以下の図に、この処理流れを示します。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

123

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 14.5-1: PAM プロファイルでの患者識別管理処理ながれ
14.5.1.2 代替の処理流れ
患者識別子の連結（Link Patient Identifiers） 上述と同様の状況で、二人の重複した患者記録の融合でなく連結を、現場の処理で患者基本情報供給役に要求します。操作者は連結機能を行います。患者基本情報供給役は患者識別子連結（Patient Identifiers Link）通信文を患者基本情報消費役に送ります。
以下の図に、この処理流れを示します。

図 14.5-2: PAM プロファイルでの患者識別管理代替処理ながれ
14.5.2 患者受診情報管理
患者受診情報管理（Patient Encounter Management）は以下の処理流れを組み込みます。
14.5.2.1 入・外患者受診情報と中断事例管理
この節では、入・外患者受診情報管理処理流れを、多くの患者受診情報供給役と患者受診
情報消費役を巻き込む状況で、記述します。これは、ITI TF-1: 14.1.2 を洗練した物です。
一部の施設では中央化された患者受診情報供給役がありますが、他では異なる臨床状況（たとえば、入院と、外来、など）に応じて複数の患者受診情報管理役が使用されることがあります。システム内の実行役の役割と患者受診情報供給役と患者受診情報消費役の関係の________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

124

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

設定とを、自身の事業処理モデルを満たすように、定めるのは医療機関の責任です。
図 14.5-3 に示すように、この処理流れを行う医療機関では三個の患者受診情報供給役があり、それぞれが特定の臨床状況に応じた多くの患者受診情報消費役に使用されます。

図 14.5-3: システムと PAM 実行役役割設定
この処理流れに含まれるシステムは以下の PAM 役割を実装します:

患者受診情報供給役として働く臨床患者登録システム



患者受診情報消費役として働く補助システム



患者受診情報供給役および患者受診情報消費役として働く病院 ADT（入・退・転院管理）システム

患者受診情報消費役として働く病院補助システム



患者受診情報供給役および患者受診情報消費役として働く病院外来患者登録システム

病院 ADT（入・退・転院管理）システムと病院外来患者登録システムとは患者受診情報供給役および患者受診情報消費役の両方を果たし、同僚として協働します。同じシステム内の患者受診情報供給役および患者受診情報消費役の関係は、医療施設に実装された臨床ア
プリケーションの論理により決まります。関係の定義は PAM 統合プロファイルの範囲外です。
図 14.5-4 の処理流れを以下の様に記述します:


患者登録:

患者は年一回の検診のため診療所に到着します。患者の記録は患者基本情報供給役により以前に作成されており、患者基本情報供給役と群形成して形成された診療所の登録システム内にあります。診療所の患者登録システムは患者登録（Patient
Registration）通信文を現場の補助システムと関連病院の ADT システムとに送ります。


外来から入院への変更:

患者の診察で深刻な状態が明らかとなり、緊急入院が勧められます。患者は入院のため関連病院に紹介されます。外来から入院患者への変更（Change Outpatient to Inpatient）通信文が病院 ADT システムへ送信されます。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

125

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________



患者の仮入院（Pre-Admit Patient for Hospitalization）:

患者は病院に仮入院して関連する検査を受けます。病院 ADT システムは患者仮入院（Patient Pre-Admit）通信文を病院の補助システムへ送ります。


患者入院通知（Patient Admitted Notification）: 検査で深刻な状態が確認され、病院の ICU に入院します。病院 ADT システムは入院通知（Admission Notification）通信
文を補助システムへ送ります。



患者保健情報更新（Patient Insurance Information Update）: ICU 入院中に患者の保険が確認され、更新情報が病院 ADT システムから複数の補助システムへ送られます。



患者転床（Patient Location Transfer）: ICU に一日いて、患者の状態は改善し、通常の病床へ転送されます。病院 ADT システムは病院補助システムに患者転床（Patient
Transfer）通信文を送ります。



患者転床過誤訂正（Patient Transfer Error Reconciliation）: 転送の記録を付ける看護師が誤りを犯し、間違った病室と病床を送信します。誤りの発見後に、病院 ADT シ
ステムは病院補助システムに患者転床取消（Cancel Patient Transfer）通信文を送り、次いで、新しい患者転床通信文を病院補助システムに送ります。



患者退院待ち（Patient Pending Discharge）: 患者は回復し、退院間近となります。
病院 ADT システムは病院補助システムに患者退院待ち（Patient Pending Discharge）
通信文を送ります。



入院から外来への変更（Change Inpatient to Outpatient）: 入院病院の手順にしたがい、患者は経過観察の検査を受けるため外来ユニットへ転送されます。病院 ADT シス
テムは病院補助システムに入院から外来へ変更（Change Inpatient to Outpatient）通信文を病院外来患者登録システムに送ります。



外来患者に登録（Register Patient as Outpatient）: 患者は病院の外来患者登録シス
テムに登録され、このシステムから病院 ADT システムと病院補助システムに患者登録（Patient Registration）通信文を送ります。



外来患者システムからの退出（Patient Discharge from Outpatient System）: 患者の外来での受診は完了しました。患者退院（Patient Discharge）通信文が病院 ADT シ
ステムと病院補助システムへ送られます。



病院 ADT システムからの退院（Patient Discharged from Hospital ADT system）: 検
査結果が満足すべきものだったので、患者は退院しました。病院 ADT システムは患者
退院（Patient Discharge）通信文を病院補助システムに送ります。

以下にこの使用例での処理流れを示します。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

126

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 14.5-4 PAM プロファイルでの入・退院患者受診管理処理ながれ
14.5.2.2 高度受診管理

受持医交替（Attending Physician Change）: 入院中に受持医の変更があった。患者
受診情報供給役は患者受診情報消費役に新しい受持医の名前を含む通知文を送ります。



受持医交替取消（Cancellation of Attending Physician Change）: 受持医の変更通知が誤って送られました。患者受診情報供給役は患者受診情報消費役に古い受持医の名前を含む取消通知文を送ります。



外出・外泊（Leave of Absence）: 入院患者が医療センターから許可され週末に外泊します。患者受診情報供給役は患者受診情報消費役に外泊の開始日時と予定の帰院日を含む通知文を送ります。



外出・外泊取消（Cancellation of Leave of Absence）: 週末外泊許可の通知が誤って送られました。患者受診情報供給役は患者受診情報消費役に外泊の取消通知文を送ります。

帰院（Return from Leave of Absence）: 患者は週末外泊から医療センターに戻りました。患者受診情報供給役は患者受診情報消費役に外泊からの予定の帰院日と実際の帰院日とを含む通知文を送ります。



帰院取消（Cancellation of Return from Leave of Absence）: 帰院通知文が誤って送られました。患者受診情報供給役は患者受診情報消費役に外泊の取消通知文を送ります。



会計口座移動（Move Account）: 患者受診情報供給役は誤って患者 A の会計口座を12345 としました。
実際は患者 B の会計口座が 12345 でした。
訂正を有効にするため、________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

127

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

患者受診情報供給役は、会計口座識別子と患者識別子の記録を保持しこの間で連携を移動する、患者受診情報消費役に通信文を送ります。
以下にこの使用例での処理流れを示します。

図 14.5-5 PAM プロファイルでの高度受診管理処理ながれ
15.5.2.3 移動履歴管理
患者の入院、退院、その他の移動の記録がある種の医療機関では必要となることがあります。この様な履歴は療養の一事例の境界を越えて、追跡する必要があることがあります。
この履歴追跡を容易とするため患者受診情報供給役は患者受診情報消費役に、ITI TF-1:
14.5.2.1 から 14.5.2.2 の通信文を、患者の入院、退院、その他の移動と関連する特定の受診情報を、識別子を添えて送ります。


患、者居所移動（Patient Location Transfer）: 患者は ICU に 2-3 日いたあと、病室 Bのベッド 23 へ転床しました。病院 ADT システムは患者移動通信文を（移動履歴管理
オプションに含まれる要素を含んで）下流アプリケーションへ送ります。



移動履歴の更新（Update Previous Transfer Event）: ２日後、ADT システムの操作者は以前の患者移動通信文中の移動先と時刻とが誤りであることに気づきました。操作者は誤りを訂正し、患者移動履歴更新通信文が、正しい病室・病床情報と転床を通信するため送られました。

以下にこの使用例での処理流れを示します。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

128

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 14.5-6 PAM プロファイルでの移動履歴管理処理ながれ
14.5.2.4 一時患者移動追跡

一時的居所への出発（Departure to Temporal Location）: 入院患者に胸部Ｘ線写真が予定されました。この診療のため、患者は療養中の入院ベッドから放射線科へ移動する必要があります。患者が病床を離れたとき、患者受診情報供給役は患者受診情報消費役に、患者が移動する一時的な居所を含む通信文を送ります。



一時的居所への到着（Arrival at Temporal Location）: 患者が放射線科に到着したとき、患者受診情報供給役は患者受診情報消費役に、患者が到着した一時的な居所を含む通信文を送ります。



一時的居所への出発取消（Cancellation of Departure to Temporal Location）: 患者が入院病床から心臓病科へ治療を受けに移動したと誤って通知されました。患者受診情報供給役は患者受診情報消費役に、患者の一時あるいは永続的居所を含む通信文を誤って伝えられた出発時刻より前に取消の通知文を送ります。



一時的居所への到着取消（Cancellation of Arrival at Temporal Location）: 患者は入院病床を出て治療のため外科に到着したと誤って伝えられました。患者受診情報供給
役は患者受診情報消費役に、患者の一時あるいは永続的居所を含む通信文を、誤って伝えられた到着時刻より前に取消の通知文を送ります。

以下にこの使用例での処理流れを示します。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

129

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 14.5-7 PAM プロファイルでの一時移動追跡処理ながれ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

130

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

15 XDR 統合プロファイル
施設間高信頼性書類交換 Cross-Enterprise Documanet Reliable Interchange, XDR）は高
信頼性の通知システムを使用した書類の交換です。これにより、XDS 登録所や保管庫の様な書類交換の基盤が存在しない状況での、EHR、PHR、その他の医療機関 IT システム間の直接的書類交換を可能にします。
XDR は EHR の間で一人の患者の書類とメタデータを XDS 基盤の無い状態でも、信頼できる、自動的な書類転送を提供します。XDR はウェッブサービス都ともに提供とセットの登録（Provide and Register Set ）トランザクション-b の再使用を移送として、可能にします。転送は直接、源から消費役に行われ、登録所や保管庫を介しません。
XDR は書類形式を関知せず、XDS と XDM とで同じ書類内容物を使用可能とします。書類
内容は、XDS 書類内容プロファイルに記述されています。例として、XDS-MS, XD-LAB,
XPHR, XDS-SD があります。
XDR は新しいメタデータや通信文の形式を定めません。患者識別、書類識別、記述、関係に重点を置いた XDS メタデータに影響します。

15.1 実行役・トランザクション
図 15.1-1 に XDS-R 統合プロファイルに直接含まれる実行役と、この間での関連のあるト
ランザクションを示します。XDS、PIX、XUA に参加するため間接的にこのプロファイルに含まれる他の実行役は示されていません。

図 15.1-1: XDR 実行役の図
表 15.1-1 に、XDR プロファイルに直接含まれる実行役のそれぞれについて、トランザクシ
ョンを列挙します。この統合プロファイルが使用可能と主張するには、すべての必須トラ
ンザクション（"R"と表記）が実行可能でなければなりません。"O"と表記されたトランザ
クションはオプションです。この統合プロファイルで定義され、実装品が選択可能なオプ
ションの完全な一覧は第一巻、15.2 節にあります。
表 15.1-1: XDR 統合プロファイル－実行役とトランザクション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

131

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

15.2 統合プロファイルオプション
この統合プロファイルに選択可能なオプションは、これが適用される実行役とともに、表15-2 に列挙されます。オプション間の依存は、もし適用可能ならば注記されます。

表15.2-1: XDR －実行役とオプション

15.2.1 意図的に空白
15.2.2 基本患者プライバシ強化オプション
このオプションについては、ITI TF-2b: 3.41.4.1.3.1 を参照してください。

15.3 XDR 処理流れ
XDR は医療提供機関、たとえば医師、病院、特別医療ネットワーク、あるいは他の医療専門家の間で、一患者の一組の書類の交換を記述します。
XDS 登録所・保管庫が実装されていないか使用可能でないときには、XDR は貴重な方法です。
情報が自動化アプリケーション、あるいは、一人の患者の書類の自動保存や処理が可能な
汎用システムに情報が送られる状況では、XDR は適切なプロファイルです。
XDR 統合プロファイルは患者に関連する医療書類の交換のみを意図したもので、全ての施設間 EHR 間通信の必要を処理することを意図していません。
使用例:1.

医師の Primary 氏は、彼の老いている患者の Robinson 氏を胃腸専門医に紹介して、初回の予約を取ります。
胃腸クリニックには XDS 保管庫がないため、医師の Primary 氏は Gastro 医師へのXDS-MS 紹介を XDS を使用して通信することができません。さらに、医師の Primary
氏と Gastro 医師を結ぶ提携医療圏も無いため、Robinson 氏の紹介情報を交換するには XDS よりも XDR のほうが好ましいです。
XDR は Gastro 医師の書類を医師 Primary
氏へ通信するにも好適です。
Mabel さんは病院から長期療養のため退職者ホームへ転送されます。
XDR: Mabel さんの情報は病院から長期療養施設の EHR アプリケーションへ転送でき、________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

132

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

受持医と看護師が XDR をとおして閲覧するのに備えます。
2.

Stanley さんの最近の MRI で、見慣れない結果が出たため、Stanley さんのかかりつ
け医は州を超えた所の専門癌施設にいる別の専門科に相談したいと思います。遠隔の医療施設との間では連携医療圏はありそうもないので、XDR がかわりに使用できます。

3.

Sweettooth さんは成人型糖尿病と診断されていますが、彼女の特殊療養施設は共通の保管庫を共有する様には組織されていません。そうなるまでは、XDR を使用して一対一で情報を交換する必要があります。

この統合プロファイルはこの様な使用例でのデジタル転送機構を定めるだけで、伝達される内容は、IHE PCC（Patient Care Coordination）領域で規定された様な内容プロファイ
ルで詳細が決められます。

図 15.3-1: XDR プロファイルの処理流れ

15.4 デジタル通信
HTTP 通信文に基づくウェッブサービスです。

15.5 安全の考慮
このプロファイルは、書類源と書類受領役を使用する医療機関同士はどのような時に PHIを交換できるかを定めていることを前提としています。これには明示的な患者承諾が（規制によっては）必要なことがあり、安全についての基本方針の矛盾を管理する方法についての合意が必要なことがあります。
この合意に含まれるべき主要な面は XDS に似ています。
付録 L を参照してください。XDR の場合には、HER-HER（あるいは PHR）間の通信は、一時的な XDS 連携圏です。加えて、以下の面が含まねばなりません。
；


書類の読み込みに際して、患者情報の整合性が正確にとられる様にするための患者識
別の管理
このプロファイルの両方の実行役は安全拠点と群形成せねばなりません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

133

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

16 施設間書類媒体交換統合プロファイル
施設間書類媒体交換（Cross-ENtetprose Document MEdia Interchange, XDM）統合プロ
ファイルは、数種類の標準的記録媒体に、共通のファイルとディレクトリ構造を使用しての書類交換を提供します。これにより、患者は医療書類を物理的媒体で持ち運ぶことができます。これはまた、医学書類の人対人の電子メールによる伝送を可能にします。XDM は複数患者に関連するデータを一回のデータ交換で転送することを可能にします。
医師から患者から医師－Bob は MRI を受け、癌と診断されました。MRI の結果と紹介情報
を含む CD-R を、好きな専門医に渡す様にと手渡されました。
患者の救急科来院－さらに、Bob は、説明を受けて自身の EHR のコピーを家に有しており、
CD-R を持って、癌と関係のない緊急症状で救急科を訪れます。
医師から医師－医師 Primary は年老いた患者 Robinson 氏を胃腸科の専門医にはじめて紹介します。医師 Primary は専門医への電子メールに関連のある書類を zip ファイルとして添付し、送信します。
これらの使用例に共通の脈絡は人対人の通信であることです。XDM による解決は既存の電メールソフト、CD 書き込みソフト、USB に容易に実装できるよう、意図しています。xdmには他の信頼性向上の手だてを持ちません。XDM では、データ受領側はデータの取り込みを制御する（患者 ID 整合性、媒体上の複数患者データから対象患者のデータを選ぶ）ため人が介在することを必須としています。
XDR は書類形式を関知せず、XDS と XDM とで同じ書類内容物を使用可能とします。書類
内容は、XDS 書類内容プロファイルに記述されています。例として、XDS-MS、XD-LAB、
XPHR、XDS-SD、XD*-LAB があります。
XDR は新しいメタデータや通信文の形式を定めません。患者識別、書類識別、記述、関係に重点を置いた XDS メタデータに影響します。
ディレクトリとファイル構造は媒体に書類を入れるために記述されています。この構造は列挙された患者毎に別々の領域を確保し、言及されたすべてのタイプの媒体で使用可能です。媒体と構造は放射線部門での媒体相互運用性の経験（すなわち、PDI プロファイル）にもとづいて選択されています。選択された媒体は、CD-R、USB 可搬媒体、ZIP ファイル
添付の電子メールです。

16.1 実行役・トランザクション
図 16.1-1 に XDM 統合プロファイルに直接含まれる実行役と、この間での関連のあるトラ
ンザクションを示します。XDS、PIX、XUA に参加するため間接的にこのプロファイルに含まれる他の実行役は示されていません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

134

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 16.1-1: XDM 実行役の図
表 16.1-1 に、XDM プロファイルに直接含まれる実行役のそれぞれについて、トランザク
ションを列挙します。この統合プロファイルが使用可能と主張するには、すべての必須ト
ランザクション（"R"と表記）が実行可能でなければなりません。"O"と表記されたトランザクションはオプションです。この統合プロファイルで定義され、実装品が選択可能なオプションの完全な一覧は第一巻、15.2 節にあります。
表 16.1-1: XDM 統合プロファイル－実行役とトランザクション

16.2 XDM 統合プロファイルオプション
この統合プロファイルに選択可能なオプションは、これが適用される実行役とともに、表16-2 に列挙されます。オプション間の依存は、もし適用可能ならば注記されます。
表 16.2-1: XDM －実行役とオプション

注１: これらのオプションの少なくとも１つがそれぞれの実行訳に必須です。相互運用性を高めるため、実行役はすべてのオプションを使用可能とすることを強く推奨します。
注２: このオプションは電子メール付属 ZIP(ZIP over Email)オプションが必須です。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

135

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

16.2.1 USB オプション
このオプションでは、携帯媒体生成役（Prtable MEdia Creator）は一セットの書類を USB
媒体に書きます。媒体は物理的に携帯媒体読み込み役（Portable Media Inporter）に運ばれ、ここで書類セットが読み込まれます。
16.2.2 CD-R オプション
このオプションでは、携帯媒体生成役（Prtable MEdia Creator）は一セットの書類を CD-R
媒体に書きます。媒体は物理的に携帯媒体読み込み役（Portable Media Inporter）に運ばれ、ここで書類セットが読み込まれます。
16.2.3 電子メール付属 ZIP（ZIP over Email）
このオプションでは、携帯媒体生成役（Prtable MEdia Creator）は一セットの書類を含む可能メディア上の通常 ZIP ファイルを生成します。
ZIP ファイルは電子メールに添付され、携帯媒体読み込み役（Portable Media Inporter）に送信され、書類セットが読み込まれます。
16.2.4 電子メール付属 ZIP 応答（ZIP over Email Rsponse）
このオプションでは、可搬媒体読み込み役（Portable Media Importer）は応答（MDN 基盤）を可搬媒体読込み役（Portable Media Importer: 訳者注: Portable Media Creator の間違い？）に送り、受け取った書類セットの読み込みが成功したことを通知します。
このオプションを使用可能とするときは、電子メール付属 ZIP（ZIP over Email）オプショ
ンが使用可能でなければなりません。

16.3 XDM 処理流れ
XDM は医療提供機関、たとえば医師、病院、特別医療ネットワーク、あるいは他の医療専門家の間で、一患者の一組の書類の交換を記述します。
XDS 登録所・保管庫が実装されていないか使用可能でないときには、XDR は貴重な方法です。
情報の受け手が、物理的媒体を扱うがごとく、データと付属書類を用手的に解釈したり調べる状況では、XDM が使用されねばなりません。XDM では複数の患者に間れうする書類の交換を許しますが、これは、人が介在して用手的に解釈されるからです。
XDM 統合プロファイルは患者に関連する医療書類の交換のみを意図したもので、全ての施設間 EHR 間通信の必要を処理することを意図していません。ある種の使用例では、XDS、
DSG、PIX、ATNA のような他の IHE 統合プロファイルを必須とすることがあります。他の使用例では一部のみが使用可能であったり、残りでは将来の IHE 統合プロファイルを必要とすることもあります。
使用例:
1.

医師の Primary 氏は、彼の老いている患者の Robinson 氏を胃腸専門医に紹介して、________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

136

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

初回の予約を取ります。
医師の Primary 氏の診療室、または胃腸クリニックには安全に電子メールを扱うことができない、あるいは、持続的な点対点のオンライン接続（たとえば、http overVPN）がないため、XDM プロファイルはより単純な環境に対応した追加の解決法、
たとえば、物理的媒体の使用、電子メール添付ファイルの人により用手的に解釈されるなど、を提供します。
2.

XDS 基盤を持たない病院では；XDS-MS 内容プロファイルの退院使用例は XDM で扱えます。たとえば:
汎用 EHR を使用していない病院や家庭医の場合、退院情報を記録された CD や
USB を家庭医の経過観察に持ち込んで、患者が扱えます。

3.

Marbel さんは長期療養のため、病院から退職者ホームへ転院します。
病院が、患者の医療データを自動的に解釈し患者の必要な医療チーム員の間で共有する EHR アプリケーションを持っていないときには、情報は用手的に、施設の形態に従って、事務クラーク、入所コーディネータ、記録管理者、あるいはかか
りつけ医に渡されます。

4.

Stanley さんの最近の MRI で、見慣れない結果が出たため、Stanley さんのかかりつ
け医は州を超えた所の専門癌施設にいる別の専門科に相談したいと思います。遠隔の医療施設との間では連携医療圏はありそうもないので、XDM がかわりに使用できます。

5.

Bob さんは、説明を受けて自身の個人医療記録（PHR）のコピーを家に有しています。
この状況では、Bob さんは医療情報を記録した CD-R の様な物理媒体を渡されることができ、媒体を家に持ち帰ります。Bob さんは、急な救急科受診の時にも、それが州をでる旅行の最中で新しくかかる救急科が自身の属する医療連携圏の書類保管庫を利用できない状況でも、自身の完全な医療記録を使用できる利点を得ます。

この統合プロファイルはこの様な使用例でのデジタル転送機構を定めるだけで、伝達される内容は、IHE PCC（Patient Care Coordination）領域で規定された様な内容プロファイ
ルで詳細が決められます。

図 16.3-1: XDM プロファイルの処理流れ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

137

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

16.4 デジタル通信
16.4.1 実際の媒体タイプ
媒体は、電磁的情報の携帯搬送に他の産業界でもっと使用されるため、CD-R か、USB 媒体です。この補遺ではこのタイプの媒体を、使用例に応じて、使用するのを必須とします。
使用する媒体の再使用可能性の利益とリスクについての議論は、特に媒体が患者の制御下にある場合には、念頭に置くべきです。
注:
1.

交換される書類の大きさは通常 CD-R の容量をこえることが滅多にないこと、データを種々の記録可能 DVD 媒体に保存するフォーマットが未だ定まっていないことから、このプロファイル
では IHE 放射線 PDI プロファイルでの制限に従い、現時点では DVD を使用しないことにして
います。

2.

放射線領域での使用経験では CD-RW はかなりの相互運用性の問題とかなりの偶発的媒体損傷を示したことから、CD-RW はこのプロファイルから除外されています。

3.

長時間録音可能 CD-R は容量の拡張をエラー検出と訂正レベルを１つさげて行っているので、
CD-R は 74 分録音可能のタイプに限定されています。長時間録音可能 CD-R のエラー率の多さ
は医療データには適切でないと判断されました。

16.4.2 ネットワーク上の仮想媒体
媒体は安全な電子メール通信文で送信された、書類を含む ZIP ファイルです。
16.4.3 媒体の内容
媒体内容への要求事項は、患者要約、検査結果、退院状とレポート、の様な医療書類の簡単な転送を振興すること、および、療養提供者や患者が汎用コンピュータの上でこのような書類を閲覧できること、を意図しています
生成された媒体は書類と関連するメタデータとを含むよう要求されています。
媒体は、ルートから始まる規定されたデイレクトリ構造に組織化した書類と関連するメタデータからなる１個以上の提出セットを含みます。
媒体内容は、オプションの HTML 内容物を含むファイルをインターネット閲覧ソフトで閲覧できるようにすることができます。この内容は、データ一貫性のため、元の書類にもとづいて作成されねばなりません。携帯媒体読み込み役はこれを無視してかまいません。
HTML 内容物は単に、受取手が人間である場合のためです。
追加の内容（フィイル、ディレクトリ）が存在しても良いですが、携帯媒体読み込み役はこれを無視できます。
まとめると、携帯媒体取り込み役は媒体とその内容を基本的インターネット閲覧ソフトで________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

138

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

利用する２つの相補的手段を持っています
XDM に使用するディレクトリを視察すると、すべての子ディレクトリは特別に命名された
XDM に適合するメタデータのファイルを含んでいます。
HTML インデックスファイルを使用者に提示すると、媒体に含まれる提出セットと書類の一覧があります。
個々の書類の内容を手に入れる方法はこの統合プロファイルの範囲外で、特定の IHE 書類
内容統合プロファイルで扱わねばなりません。

16.5 安全の考慮
このプロファイルは携帯媒体生成役と携帯媒体取り込み役とを使用する医療機関同士はどのような時に PHI を交換できるかを定めていることを前提としています。これには明示的な患者承諾が（規制によっては）必要なことがあり、安全についての基本方針の矛盾を管理する方法についての合意が必要なことがあります。この合意に含まれるべき主要な面は
XDS に似ています。付録 L を参照してください。加えて、以下の面が含まねばなりません。
；


書類の読み込みに際して、患者情報の整合性が正確にとられる様にするための患者識
別の管理

媒体や電子メールの損失を防ぐ、あるいは、限定する方法、および、損失を検出する
方法

物理的媒体の場合には患者に媒体を渡した時点で、内容の秘匿性と完全性についての安全責任は患者に移ります。この場合、媒体を保護するのは患者の責任で、内容を開示する許可をだすのも患者の責任です。媒体をわたすことにより内容が開示されたことになります。
携帯媒体生成役は多くの場合、最終的読み込み役が誰であるかを知りませんので、暗号化は非現実的です。
ZIP 添付書類として電子メールで転送する場合は、トランザクションは S/MIME で保安されます。
このプロファイルの二つの実行役は、ATNA 安全拠点、または、安全アプリケーションと群形成される必要があります。

17 データ収集用紙回収（Retrieve Form for Data Capture）
データ収集用紙回収（Retrieve From for Data Capture, RFD）プロファイルは、使用者が現に使用中のアプリケーションの中で、外部システムの要求に答えてデータを収集する方法を提供します。RFD は書式源からの書式取得、書式の表示とデータ入力完成、データ表
示アプリケーションからデータ受信アプリケーションへの送信、を可能にします。加えて
RFD は以前に取得したデータの補遺をおこなう機構を提供します。
療養提供施設が電子化健康録（EHR）を使用して患者の療養を記録する状況を考えます。
この例では、EHR は施設職員の現場での”我が家の”アプリケーションとして働きます。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

139

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

外部機関が、ある種の契約にもとづいて、療養提供施設から一部は EHR のデータベースの値で、残りは EHR 使用者の入力で、療養提供施設からデータを集めると思ってください。
RFD は、EHR 使用者が、外部機関からデータ記録用紙を取得し、用紙を埋め、”我が家の”
アプリケーションである EHR から抜け出ることなく、データを外部機関に返送することを可能にします。このプロファイルでは外部機関が入力されたデータについて明らかにすべき必要があると指摘することとデータの修正を行う方法とを提供できるようになります。
多くの潜在的な RFD 使用では、ホストアプリケーションのデータベースにある値で、用紙の該当欄を予め埋めておくことが要望されます。RFD は自動的な値の入力とこれを行う一
般的な方法とを可能とします。しかし、このプロファイルは、内容、規定語彙に対する無回答、あるいは、その他の意味的相互運用性の確保の問題は扱いません。特定の領域群－臨床研究、医薬品安全、生物学的調査－では、内容の特定、RFD で動作する既存の内容標
準の評価と推奨などにより RFD の上にシステムを構築するでしょう。RFD は基盤となる
プロファイルとして領域特異的内容標準を統合し、もっと大きな相互運用性を達成します。
RFD プロファイルは一般的な調査機構を提供し、外部機関が入力データの問題を指摘し医療提供機関がそのデータを訂正できるようにします。このような訂正を可能とする使用機構と必要な制御については述べません。
このプロファイルでは、外部機関がその領域で適切な方法でデータ入力用紙を提供します。
表示アプリケーションが行うべき業務を極力減らし、用紙を完成するのに必要な記述法をもつ、完全に機能する調査用紙をもたらすことを意図しています。RFD は完成した調査用紙のコピーの保管を可能にします。
データ取得に使用する用紙の構造と内容を扱う産業界の標準に影響を与えることができます。HL7 の個別例安全記録（Idivisual case Safety Report, ICSR）や CDISC の運用デー
タモデル（Operational Data Model, ODM）がその例です。
EFD が提供する基盤は多くの領域群で利用できますが、いろいろな領域に特異的な使用例
から、RFD が可能にする広範な種類の使用がわかります。

17.1 使用例
以下の使用例はこのプロファイルが如何に種々の専門領域で使用されるかを示します。
RFD はこれらのすべての使用例を可能にします。以下のいずれの実装もありません。RFDの使用法と規則を規定した専門領域特異的なプロファイルが将来の領域特異的 IHE プロフ
ァイルに期待されています・
17.1.1 探索的新薬治験の使用例
臨床治験使用例の状況は臨床研究と患者の療養とが平衡して行われる医師の実地診療です。
Holbin 医療システムは、多数の施設を有し、多種の専門からなる 100 名以上の医師を雇う
実地診療です。Holbin の社長（CEO）は製薬会社が支援する臨床試験に研究施設として参加するよう、医師に奨励しています: Holbin は臨床研究活動を支援するため、研究コーディ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

140

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

ネータ 12 名、うち大部分は登録看護師（RN）で、事務員とデータ入力支援者も含む研究部門を擁しています。Holbin Medical Group は電子化健康録（EHR）を使用し、電子的データ取得システム（EDC）を臨床治験活動を記録するため、支援者からいくつかもらっています。
（ここでは EHR は患者の療養を記述する主たる場所となるあらゆるアプリケーシ
ョンで患者療養の記録を取り出せるものとします。このため、今日では厳格には EHR でな
いものも含まれますが、ここでの目的には役立ちます。
）
Holbin の臨床治験への参加は、研究スポンサからの提案要求書（RFP）を受け取ったときから始まります。研究コーディネータの Patricia Zone 登録看護師は、RFP を事業上の力、臨床的適切性を評価し、スポンサに RFD を返送します。臨床治験の施設として選ばれた後、#12234 と識別され、規制上必要な書類をスポンサに提供します。主任研究者とされた医師とその他の研究職員はスポンサから試験計画に特異的な訓練を受けます。治験準備期間に、Patricia は研究手順について適切な安全策が行われているのを確認し、参加および樹外基準に従って治験参加者を集め患者の受診非を予約し、データ取得と入力を管理し、すべての付属する経済的業務を行います。
Patricia は Holbin の患者の Corey Jones と連絡し、治験の参加を依頼し Corey は治験への参加を承認します。Patricia は Cory を治験#1234 の対象者として
EHR 患者索引を使用して EHR に登録します。Corey の研究のための来院を EHR の予約
モヂュールを使用して予定し、治験#1234 に関連する来院と印を付けます。準備期間のあと、施設は臨床治験を開始し、診療の書類と治験に特異的な書類とをつけ始めます。
この使用例は以下の現状と好ましい状況の節に続き、RFD 実装前後での EDC を使用した患者の治験用来院中のデータ取得を記述します。
17.1.1.1 現状
Corey Jones は予定された治験来院で診療部に到着し、Patricia Jpones と合い対面のイン
タビューをします。
Patricia は使用者認証後 RHR に入り、来院を書面で記録します－'Jones
さんは治験#1234 に関係する治験用来院に到来した'。Patricia は Jones さんと会話し、観察し、観察結果を紙に記述します。EHR で最近の検査結果を見て、これを症例報告用紙（CRF）に記述します。EHR には用紙の一部に該当するデータしか無く、残りはインタビ
ューと観察から得られます。
（EHR でえられる臨床治験データの割合は治験必要データの5-40％と見積もられています。最良の場合でも研究計画が要求するデータの部分セットしか典型的には取得できません）
完成した紙書類はデータ暗号化担当の Bob に渡されます。Bob は CRF が治験#1234 と認識し、#1234 用の EDC システムを選択します。このシステムはスポンサから供給されたノートパソコンにあるか、インターネットを経由してスポンサの EDC システムと接続しています。リング 3 個のバインダを棚から取り出し、このシステム使用法の”虎の巻”書類を探します。EDC アプリケーションに username とパスワードで認証を受けて入り、正しい電________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

141

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

子的症例登録用紙（eCRF）に該当の治験来院のデータを入れます。元の紙書類を処理すると、Bob は物と紙書類を、治験の永久記録の一部として箱（banker's box4）にしまいます（連邦規則 21 CFR 312: 62 の要求事項をｍたすため）。
治験#1234 に加え、Bob は 8 つの追加の EDC システムにデータ入力を行います。うち 5 個
は専用ノートパソコン、3 つはインターネット接続です。インターネット接続の ECD シス
テムは机のスペースを少なくしますが、それでも”虎の巻”使用説明書の入ったリング 3
個のバインダが必要です。特定の治験のデータが対応するノートパソコンに入力したか確認するのは、それぞれに特定の認証儀式と特定の入力用紙が必要な面倒な仕事です。Bob
はこのようなやっかいなシステムいらついています。Bob は誠実な雇われ人で仕事はいつも最新で貯めタリしません。多くの施設ではデータ入力係はしばらく CRF を持ったままでたいてい月に 2 回程度の入力、あるいは、治験モニタ来訪一週間前に入力するのが関の山です。
17.1.2 望ましい状態
Jones さんが来院し、Partica は認証をうけて EHR に入ります。Jones さんの記録を選び、予定された治験用来院であることを認識します。治験準備期間に患者識別と来院予定が組まれたので、EHR は Jones さんを治験#1234 の対象と認識し、RFD を使用して、治験#1234の EDC システムに電子化 CRF を要求します。治験が複雑ですと、取得した複数の CRF から Partica が選択します。正しい脈絡が ECD と EHR の間にできると、Patricia は EHR
アプリケーションの臨床研究のタブを選び、適切な CFR が表示されます。EHR は Patriciaの信任状を確認し用紙を見る権限があることを確認して用紙を表示します。データ収集用
紙は EDC がこの来院に与える用紙と同じですが、EHR の使用者インターフェースと似た見かけに表示されます。虎の巻はまだ必要ですが、用紙の記述法の情報を持つもっと洗練された用紙もあります。
Paricia は Jones さんをインタビューし、臨床治験用紙にデータを入れます。EHR データ
ベースからデータが予め適切な欄に（編集チェックを組み込めば）入れることもできます。
書類を完成したら、Patricai は「提出」ボタンを押します。EHR システムは完成した用紙
を EDC に RFD を使用して送信します。書類のコピーが施設の臨床治験保管庫に治験の永久記録の一部として保存されます。

4

定義は http: //www.archivisits.org/glossary/term_detaiks.asp?DefinitionKwy=1193 をみて下さい。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

142

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

17.2.1.3 炭疽菌、鳥インフルエンザシナリオ: 仮診断や患者”問題”に基づいた疾患看視炭疽菌:

患者が急速に振興する呼吸器症状で救急科（ED）を受診した。喀痰のグラム染

色でグラム陽性桿菌が、見つかり、胸部Ｘ線写真では縦隔の拡大があり、患者の状態は急速に悪化した。検査室での痰培養では炭疽菌が疑わしいとの結果だった。州の健康省（DOH）
は病院と接触し検体を確認のため送付した。いったん炭疽菌と確認されると、州 DOH は適
切な地区、地域、州および連邦当局（たとえば、CDC, FBI, USAMRID[米軍感染症研究所]）に通知し、さらに、地区の病院、療養提供者、メディアに通知します。
（患者識別の後には、
生物テロリストのシナリオがあります。以下のインフルエンザのシナリオでもおそらく同じことがおきます）
追加の症例の可能性が通知されると、急速に振興する呼吸器症状の患者には、ED は痰のSTAT グラム染色と、正側の胸部Ｘ線写真を、それぞれ施行します。グラム陽性桿菌が存在すると、内部および外部の（疾病）監視レポートのため、検査システムに直接入力される
か、指定された救急室（ER）職員により CIS（臨床情報システム）の患者 ADT 画面の特定のデータ野に入力されます。胸部写真の迅速読影で縦隔拡大があると、指定された職員（たとえば放射線技師）が医師に代わって、ADT 画面の特定のデータ野に入力されます。
これらデータ野に値が入力されると、現場を管轄する公衆衛生生物監視システム（BIS）に対する情報のトランザクションが、吸入炭疽菌感染症と仮診断されたとして行われます。
BIS は複数箇所からのデータを集積し、仮あるいは確定診断された炭疽菌感染症の発生場
所、起源、広がりを提示します。
インフルエンザ: 病院近隣の医師、ED 医師はウイルス感染を疑わせる呼吸器症状患者の増加を知りますが、周囲の病院では同様な症状患者の増加がありません。インフルエンザ A/B
迅速テストは多くの患者で陽性であり、インフルエンザ流行が地域に広まっています。呼吸器由来検体の培養は 24 時間では細菌が陰性でインフルエンザ A ウイルスが陽性でした。
患者間の相互接触と死んだ鶏とから、AH5N1 が疑われます。すべての検体は州の DOH
ASAP へ同定のため送られます。州の検査室で AH5N1 と同定します。上記と同様の経緯です。健康局から現地の療養提供者へ通知が流布されたあとの経緯は、仮診断の情報が好手
衛生 BIS へ伝えられるのと同様です。上記のいずれのシナリオでも、仮診断を集める汎用的方法は、オーダ発行、医師、看護に使用する CIS の日常運用の一部として、標準化された「問題」用語（SNOMED 使用）を選択する方法です。
上記二つのシナリオの違いは、炭疽菌の例が症候群（重症の呼吸器症状と胸部 X 線写真での縦隔拡大: これには放射線検査監視と ED と検査室での相互参照が必要で複雑）にもとづいた監視であることです。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

143

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

17.1.3 薬物監視シナリオ
Cramp 医師は外来で患者を診察し、電子健康録（EHR）を利用して、患者が新しいスタチ
ン薬の一種を服用していることを知ります。診察で患者のふくらはぎの筋力低下を見つけ、医師はスタチンの副作用と気づきます。診断のため総クレアチニンキナ－ゼ検査をオーダします。
17.1.3.1 現状
Cramp 医師は EHR を閉じて、インターネット閲覧ソフトにより http: //fda.gov/medwatch/を開きます。FDA 様式 A3500「 臨床診療のなかで自発的に気づかれた有害事象の任意通報」を持ってきます。案内ページや記入法のページを経て、実際の様式の最初のページに到達します。最初のページでは、患者識別子、発症時年齢または誕生日、体重を入力します。次のページには 7 項目あります。事例の分類、転記の分類、発症日、通知日、記述、関係のある検査所見、その他の関連のある病歴（最後の 3 つは文章入力）、です。3 頁目、4頁目は製品の詳細を入力します、以後同様です。
17.1.3.2 望ましい状況
Cramp 医師は上記の様に患者を診察して EHR を利用します。問題を発見すると、”有害事象報告”ボタン押して FDA 様式 3500 を、EHR のインターフェースから、持ち込みます。
様式の患者基本情報欄はすでに埋められています。製品名は、現に EHR で使っている文脈の一部なので、適切な入力欄に自動的に入力されます。Cramp 医師はその他の情報を入力し、直接 FDA Medwatch へ投稿します。
RFD は Medwatch から様式を取得し、表示し、FDA への様式返送を行います。このプロファイルは EHR が様式を保持しているか、EHR データを予め取得しておくか、については処理しないことに注意してください。単に、EHR を使って、表示し、記入を完成し、返送するだけて十分です。EHR とその施設は、EHR の中に（記入した）様式のコピーを保存すると決めることもありますが、これはこのプロファイルの拡張であり、必須ではありません。

17.2 実行役・トランザクション
図 17.2-1 に、データ収集用紙回収統合プロファイルに直接含まれる実行役とこれらの間の関連するトランザクションを示します。他の統合プロファイルに参加することにより間接的に含まれれる実行役は示されていません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

144

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 17.2-1: データ収集用紙回収実行役図
表 17.2-1 に、データ収集用紙回収統合プロファイルに直接含まれる実行役のそれぞれに対するトランザクションを示します。実装品がこの統合プロファイルが使用可能と主張するには必須（"R"と表記）のトランザクションを実行できねばなりません。"O"と表記された
トランザクションはオプションです。この統合プロファイルに定義され、実装品が選択可
能なオプションの完全な一覧は 17.3 節にあります。
表 17.2-1: データ収集用紙回収統合プロファイル－実行役とトランザクション

17.2.1 実行役
17.2.1.1 用紙管理役（Form Manager）
用紙管理役は用紙記述役に用紙取得要求にもとづき、用紙を供給します。ある場合には、用紙記述役は単に蓄積した用紙から用紙を返送するだけですが、一方他の場合には、用紙取得要求でもたらされた状況の情報にもとづいて、用紙を選択したり、組み上げたりします。さらには、用紙保管庫についての追加の情報が用紙記述役からもたらされるか否かにより、用紙の蓄積から取得した用紙を変更したりします。用紙管理役は用紙を取得する要求に答えて、用紙とともに用紙インスタンス ID を返すことができます。
17.2.1.2 用紙記述役 (Form Filler)________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

145

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

用紙記述役は用紙管理役から、必要に応じて必要なとき、用紙を取得します。用紙を要求するとき、用紙記述役は、用紙管理役が使用できるように、事前に用紙の欄に入れておく
xml データの提供による EHR 状況情報と、さらに、用紙の選択を容易にする業務流れのデータも、オプションで、要求に加えて送ります。
用紙記述役は用紙保管庫実行役を指定することができます。用紙記述役に指定された用紙保管庫は、用紙管理役が指定する用紙保管庫に付け加えられます。
17.2.1.3 用紙受領役
用紙受領役は、用紙記述役からの、完成された、あるいは、部分的に完成された用紙個別事例データ（instance data）を受領し処理します。用紙受領役の処理は、統合プロファイ
ルの範囲外です。
17.2.1.4 用紙保管庫
用紙保管庫は完成された、あるいは、一部完成された用紙個別事例データ（instance data）
を受けとり、これを保存の目的で蓄積します。
17.2.2 トランザクション
17.2.2.1 用紙取得（Retrieve Form）
用紙所得トランザクションは用紙管理役から用紙記述役への用紙識別子を携えます。この
トランザクションではオプションで用紙記述役が用紙保管庫を指定できます。状況情報と業務流れ情報を含む追加情報が要求とともにもたらされることがあり、要求された用紙の選択と事前の用紙への値入力を容易にします。割り当てられた用紙識別子の値により、用紙の書式が定まります。用紙識別子の割り当てはプロファイルには定めませんが、用紙記述役と用紙管理役との間に必要な設定作業の一部として割り付けが行われると思われます。
17.2.2 用紙提出（Submit Form）
用紙提出トランザクションは、用紙記述役が用紙個別データ（formm instance data）を用紙受領役に提出できるようにします。
17.2.3 用紙保管（Archive Form）
用紙保管トランザクションは、用紙記述役が用紙個別データ（form instance data）を用紙保管庫に提出できるようにします。
17.2.4 説明書取得 （Retrieve Clarifications）
説明書取得トランザクションは、用紙記述役が用紙管理役から任意の組織の説明書を要求できるようにします。割り付けられた組織識別子の値により、説明書の命名されたオプシ
ョン書式が決まります。組織識別子の割り当てはプロファイルには定めませんが、用紙記述役と用紙管理役との間に必要な設定作業の一部として割り付けが行われると思われます。

17.3 データ取得用紙回収のオプション
この統合プロファイルに選択可能なオプションを、それが適用される実行役とともに、表17.3-1 に示します。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

146

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

表 17.3-1: 実行役とオプション

17.3.1 用紙保存オプション
用紙取得オプションは、用紙記述役が、保存の目的で、用紙個別事例データを用紙保管庫に提出できるようにします。
17.3.2 データ説明書オプション
データ説明書オプションは、用紙記述役が用紙管理役から説明書を取得し、以前に提出したデータを更新して、用紙受領役に提出できるようにします。
17.3.3 XForms オプション
XForm オプションは、用紙記述役と用紙管理役が XForm 書式で用紙を交換で着るようにします。このオプションに課される制限については ITI TF-2b: 3.34.4.1 を見てください。

17.4 データ取得用紙回収処理流れ
この節では、用紙がデータ収集用に取得され、部分的に完成、あるいは、完成した後で提出される際の、処理と情報の流れを記述します。用紙が完成したか否かの基準はこのプロファイルの範囲外です。
五つの場合が区別できます。
場合 1: これは、既知の用紙 ID (formID)を使用して用紙を取得する、単純な場合です。
用紙の識別子である用紙 ID は、臨床治験に参加するときの様に、用紙記述役に知られています。用紙 ID 値は用紙索引の公表、あるいは、個人的な連絡によっても、連絡できます。
用紙 ID を取得する方法はこのプロファイルの範囲外ですが、用紙取得要求の前提です。
用紙管理役と用紙受領役とは同じシステム内で群化され、用紙源として機能します。
用紙記述役は用紙管理役に用紙取得要求を送ります。用紙管理役は、要求された用紙を返すか、用紙が使用できない旨のエラーを返します。用紙が返されたとき、用紙記述役は用紙個別事例データを用紙提出トランザクションを使用して用紙受領役にその後、提出します。用紙管理役と用紙受領役は群化されているので、両者の間に部分完成の用紙の場合の様に、通信があるかも知れませんが、これは内部通信ですので、IHE 治乱座クションではありません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

147

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 17.4-1: 場合 1: 用紙取得と用紙提出；用紙管理役は用紙受領役と一括化
場合 2: これは、用紙受領役が孤立（すなわち、用紙管理役と群化されていない）している
場合を説明します。
この図説では二つの用紙受領役があります: 1) 用紙記述役と群化された中間の用紙受領役；
2) 最終の、群化されていない用紙受領役、です。
用紙の識別子である用紙 ID は用紙記述役に知られています: 途中で用紙を保存することのできる一つのシステム内に用紙記述役と用紙受領役があります。これとは別に、最終的に用紙データを保存する、別システム上の用紙受領役があります。
用紙記述役は用紙管理役に用紙取得要求を送ります。用紙管理役は、要求された用紙を返すか、用紙が使用できない旨のエラーを返します。用紙が返されたとき、用紙記述役は部
分的に完成した用紙を中間の用紙受領役に送ります。この部分完成した用紙は、用紙管理役に当てたもう一つの用紙受領取得要求で取得でき、最終的に完成された用紙を、最終的に保存する、孤立の、たとえば、国のデータ登録書の様な、用紙受領役に提出できます。
提出するための動作は用紙によって制御されますので、提出後の動作を用紙の選択によって、あるいは、新たな生成により、望む動作を用紙取得トランザクションの処理の中で、定める責任が用紙管理役にはあります。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

148

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 17.4-2: 場合 2: 用紙取得と用紙提出；用紙管理役は用紙受領役と別。
場合 3: これ場合は、用紙記述役が保存オプションを使用します。
用紙記述役は用紙取得要求を、指定された用紙保管庫に用紙を保存する必要がある旨を示して、用紙管理役に出します。用紙管理役は、要求された用紙を返すか、用紙が使用できない旨のエラーを返します。用紙管理役は用紙記述役の用紙取得要求に指定された用紙保管庫に用紙保存のトランザクションを実行できる様に用紙を構成します。用紙が戻され次いで提出されるとき、用紙個別事例データは用紙受領役と用紙保管庫に提出されます。

図 17.4-3: 場合 3: 用紙取得、提出、と用紙保存提出
例 4: この例は、用紙 ID が事前にわからない場合の問題を解決するため用紙デザインを使________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

149

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

う一方法を示します。
用紙の識別子である、用紙 ID（formID）が用紙記述役にわかっていませんが、内容値（名前、値）の対の一セットがわかっています。これらの値を入力すべき内容用紙は、用紙 IDを持ちます。内容用紙の事例データで集められた情報を用紙管理役が使用して、用紙記述役に戻すべきデータ収集書類を決めます。
用紙記述役は、実際のデータ収集用紙を用紙管理役が決める補助となる情報を集める内容用紙を請求できるだけの情報を持っています。用紙記述役は内容用紙の一事例を完成し、これを用紙取得役に提出すると、新しい事例データあるいは、新しい用紙を戻します。

図 17.4-4: 場合 4: 用紙取得；用紙提出
例 5: この例では、用紙記述役はデータ説明書オプションが使用可能です。
用紙記述役は用紙管理役に説明取得要求を送ります。用紙受領役と用紙管理役との相互作
用はこのプロファイルの範囲外です。用紙管理役に説明情報を提供する解決法の一例は、用紙管理役と用紙受領役を図 17.4-5 と 17.4-6 の様に、群化することです。用紙記述役が送る要求には組織識別子が入っており、用紙管理役は要求を発した組織に関連する説明書のセットのみを返送することができます。用紙管理役は必要な情報を含む用紙を返して、要求を発した部所あるいは組織がデータを必要に応じて補遺する要求できるようにします。
この様な説明書取得要求は、用紙記述役により定期的に行われねばなりません。要求の頻度は用紙管理役・用紙受領役とで決められ、あるいは合意された期間により定められると思われます。
用紙管理役は変更すべきデータを含む用紙か、他の用紙への参照一覧のいずれかを返します。後者の場合には、参照された個々の用紙は用紙取得トランザクションで取得されます。
いずれの場合も、データは変更されたうえ、用紙提出トランザクションにより、用紙受領
役に提出されます。提出されたデータは、その後適切な扱いのため、データ管理役に評価されます。
このプロファイルではこれら二つの反応を区別せず、用紙にかかれて返送された内容で、________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

150

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

用紙記述役の使用者が、返送された用紙を適切に処理できる様にします。

図 17.4-5: 場合 5: データ説明書オプションが使用可能な用紙記述役

図 17.4-6: 場合 5: データ説明書オプションが使用可能な用紙記述役

17.5 安全の考慮
17.5.1 RFD リスク分析とリスク評価
RFD のリスク分析には、資産、脅威と軽減策があります。リスクデータの完全な一覧は IHEに保存され、IHE から取得可能です5。

5

リスク分析データは ftp://ftp.ihe.net/IT_infrastructure/iheitiyr5-2007-2008/Techniaal_Cmte/Profile_Work/RFD/RFD%20Risk%
Analysis%202007-05-15.xls にあります。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

151

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

リスク評価の目的は、RFD 実行役を実装する際、販売者が考慮するよう助言されるリスクのいくつかを知らせることにあります。IHE の一般的なリスクと脅威については、ITI TF-1:
付録 L を参照してください。
多くのリスクは IHE プロファイルでは解決できず、かわりに、軽減策の責任は、販売者、時に連携圏、個々の施設や実装者に転嫁されることを、販売者に助言します。この様な場合、IHE は以下の節を使用してリスクを受けた団体に通知して、IHE の責任を果たします。
17.5.2 推奨
高衝撃のリスクには、正確性の過誤、データと図式の間での相違、商業秘密の公開、があります。このプロファイルにはけいげんさくがあります。
M1. 使用者が間違った用紙を取得し他場合には、用紙を破棄します。用紙取得トランザク
ションは州が関係しないので、用紙の破棄は何の問題も起こしません。
M2. XForm オプションを使用する場合、データモデルの図式証明は XForm モデルが提供します。XForm プラグインは XForm の処理と表示の責任をおいますが、これはこの統合
プロファイルの範囲外です。
M3.

TLS の実装は可能で、プライナシ保護と施設使用者認証を要する連携圏や施設はこえを使用できます。
（実装者は TLS を実装せねばなりません。これを有効にする決定は連携圏と施設に任されます。
M4. 用紙証明（form validations）は、値が欠損している用紙の提出を防ぎます。
M5. 元データを新羅合いできる第３者のもとで保管する RFD 用紙保存トランザクション
は、施設で使用できます。
これらの軽減策（実行の責任）は販売者とその依頼人に移されます。
T1. データの入力や提出の前に、用紙提供者が提示された用紙を評価し閲覧するよう、IHE
は推奨します。提供者の閲覧で、データが正しい用紙に記されているか、正しい患者のものかを確認しますが、これは用紙回収と提出の核心的部分です。販売者は、RFD を医師が介在しない治療や診断に使用しないよう警告されています。患者のいかなる治療や診断のまえ必ず医師が介在して、送信中に起こりうるエラーがヒトにより確認される様にせねばなりません。
T2

使用可能な用紙のオプションにより、用紙内で基本的有効性確認ができるようになっています。これを利用して、入力エラーなどから守るのは、用紙開発者・実装者の責任です。
T3. 部分的に完成された用紙が必要な場合は、データを提出する組織の業務流れに問題があることを示します。
T4. 用紙や業務流れの設計者は可能であれば、用紙を順次的な段階的な用紙に分化せねばなりません。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

152

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

T5. 用紙のデザインは、業務流れとその断裂の評価を容易にするものでなければなりません。
T6. クライアント側での利用制限と安全は、情報漏洩のを軽減する重要な因子です。
T7. どのシステムが用紙記述役を果たすかを決定する際には、基本方針による制御が推奨されます。
T8. どの使用者が用紙に記述するかを決定する際には、基本方針による制御が推奨されます。
T9. このプロファイルは監査記録を必要としません。エラーを減少させ不正な使用を防ぐため、施設での監査記録システムが推奨されます。
T10. 用紙に入力したデータを元に戻す機能がアプリケーションに必要なことがあります。
T11. データ説明の必要を通知します。
T13. 用紙管理役、受領役、保管庫は保護されたシステムでなければなりません。
T14. ネットワーク、セットワーク基盤、およびシステムの強靱性の考慮が必要です。特に災害、流行、その他現地の基盤がかなり傷害された状況で使用される用紙アプリケーショ
ンでは特に必要です。
T15. 災害、流行、その他現地の基盤がかなり傷害された状況で使用されるアプリケーショ
ンでは、長い潜伏時間、狭い通信帯域での通信にあわせて用紙はデザインされねばなりま
せん。
T16.

用紙記述役は使用者のエラー、ネットワーク障害、ハードウエア障害に対して強靱でなければなりません。
T17.

要求事項を収集している時期には、業務流れを処理せねばなりません。販売者は、業務流れをクライアントと業務流れを議論するよう、助言されます。
T18. 販売者は記録と監査保管庫の実装の意味を考える様にと助言されます。

18 共同体間利用（XCA）統合プロファイル
共同体間利用（Cross-Community Access）プロファイルは、他の共同体が保有する患者に関連する医療情報を問合せ、取得する手段を可能にします。共同体は、確立された機構により臨床情報を共有する目的で、同じ基本方針のもとで協働することに同意した施設・機関の連合と、定義されます。施設・機関は EHR, PHR の様ないかなるタイプの医療アプリ
ケーションを主宰することがあります。共同体は世界規模で一意の識別子である、
homeCommunityId で識別できます。一個の施設・機関は一つの共同体のメンバーであっても、他の共同体にも属すことができます。このような共同体は、XDS により書類を共有する XDS 連携圏であったり、内部の共有構造にかかわらず、他の共同体であったりします。

18.1 実行役・トランザクション
図 18-1 に XCA 統合プロファイルに直接含まれる実行役とその間の関連するトランザクシ
ョンを示します。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

153

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

注: 図 18.1-1 に書類消費役を示すのは、18.2 節に記述される XDS 連携圏オプションの責任を明確にするためです。

図 18.1-1: XCA 実行役
表 18.1-1 に XCA プロファイルに直接含まれる実行役のそれぞれに対するトランザクションを示します。この統合プロファイルが使用可能と主張するには必須のトランザクション（"R"と表記）が実行できねばなりません。"O"と表記されたトランザクションはオプションです。この統合プロファイルで定義され、実装者が選択可能なオプションの完全な一覧
は 18.2 節にあります。
表 18-1.1: XCA 統合プロファイル－実行役とトランザクション

注:発動側あるいは応答側門番役が書類消費役と一括されるときには、追加の要求事項があります。群化については 18.2.3 節を見てください。

18.2 XCA 統合プロファイルオプション
この統合プロファイルに選択可能なオプションを、適用される実行役とともに、表 18.2-1に示します。適用される依存関係があれば、注記されます。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

154

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

表 18.2.1: XCA 統合プロファイル－実行役とオプション

18.2.1 XDS 連携圏オプション
XDS 連携圏オプションを使用可能とする画像門番役が、発動側門番役のもとにあり XDS
連携圏内にある書類消費役と、相互作用します。
このオプションを使用可能とする発動側画像門番役は:


現場の書類消費役からの登録所保存済問合せトランザクションを受け、書類消費役のために要求に応じて活動せねばなりません。現場の書類消費役からの登録所保存済問合せ トラ ンザ クシ ョン を受 ける とき は、 関連 する 要求 の入 力パ ラメ ータ とし て、
homeCommunityId を 要 求 せ ね ば な ら ず 、 登 録 所 保 存 済 問 合 せ 応 答 内 に
homeCommunityId 属性値を特定せねばなりません。homeCommmunityId については 18.3.2 節を見てください。このオプションを使用可能とする発動側門番役は、登録所保存済問合せ応答で見いだす患者識別を、門番間問合せ（Cross Gateway Query）
を受け取る応答側門番役が知っている適切な患者識別子に合うように、調節せねばな
りません。患者識別子の処理については TF-2a: 3.18.4.1.3 節を見てください。



現場の書類消費役からの書類セット取得[ITI-43]トランザクションを受け、書類消費役のために要求に応じて活動せねばなりません。現場の書類消費役からの書類セット取得 トラ ンザ クシ ョン を受 ける とき は、 関連 する 要求 の入 力パ ラメ ータ とし て、
homeCommunityId を要求せねばなりません。

発動側門番役が XDS 連携圏オプションを使用しないときは、現場の協働体内のシステムと遠隔の共同体にあるデータとの相互連携には IHE 以外の方法を使用すると期待されます。
このような独自の相互作用はこれ以上、どの IHE プロファイルでも議論されません。
homeCommunityId の詳細については関連するトランザクションを見てください。
18.2.2 非同期ウェッブサービス交換オプション
非同期ウェッブサービス交換（Asynchronous Web Services Exchange）オプションを使用可能とする発動側門番役は、門番役間問合せ[ITI-38]と門番役間取得[ITI-39]トランザクシ
ョンで、非同期ウェッブサービス交換を使用可能とせねばなりません。発動側門番役が XDS
連携圏オプションと非同期ウェッブサービス交換オプションの両方を使用可能とするなら、登録所保存済問合せ[ITI-18]と書類セット取得[ITI-43]トランザクションで非同期ウェッブ
サービス交換オプションを使用可能とせねばなりません。
18.2.3 群形成のルール
書類消費役との群形成は、発動側、および・または、応答側門番役が XDS 連携圏オプションを使用可能とする状況で使用されます。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

155

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

発動側門番役が XDS 連携圏オプションを使用可能としている時は、遠隔の共同体か、、現場の実行役かを選んで、問合せと取得ができます。このような群形成は、EHR/PHE 等の様な書類消費役が、発動側門番役に問合せて、現場の XDA 連携圏のみからでなく遠隔の共同体からも、書類の情報と内容を取得できるようにします。詳細は 18.2.31 節を見てください。書類消費役との群形成をしない発動側門番役は、単に遠隔の共同体から結果を戻してもらうだけなので、現場の EHR/PHE 等（書類消費役）は、内部および外部に向けて、別の問合せと取得のトランザクションを送らねばなりません。
応答側門番役が XDS 連携圏オプションを使用可能としている時は、書類消費役との群形成により、登録所保存済問合せ[ITI-18]と書類セット取得[ITI-43]トランザクションを使用して、門番間問合せと門番間取得を解決できます。詳細は 18.2.3.2 節を見てください。
18.2.3.1 書類消費役と群化された発動側門番役
書類消費役と群化された発動側門番役は:


XDS 連携圏オプションを使用可能とせねばなりません。



現場の書類消費役から受け取った登録所保存済問合せ[ITI-18]に応答して、現場の情報を問合せるため、登録所保存済問合せ[ITI-18]を現場の書類登録所にむけて開始せねばなりません。



現場の共同体を示す homeCommunityId を含む、現場の書類消費役から受け取った書類セット取得に応答して、書類取得[ITI-43]を現場の書類保管庫にむけて開始せねばな
りません。

図 18.2.3.1-1: 書類消費役と群化された発動側門番役________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

156

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

応答側門番役が書類消費役と群化されないときは、門番間問合せ、や門番間取得に応じて現場の情報を収集する際には非 IHE の相互連携を使用するものと期待されます。独自の相互連携はどの IHE 統合プロファイルでもこれ以上議論されません。

図 18.2.3.2-1: 書類消費役と群化された応答側門番役

18.3 XCA 処理流れ
18.3.1 使用例
一個の地域、たとえばカリフォルニア州に、数個の医療機関共同体（あるいは、XDS 連携
圏、RHIO）があるものとします。ロスアンゼルスにある一個は IHE-XDS を基盤としています。サクラメントにある一個は他の形式の診療情報共有基盤を使用しています。サンフランシスコにある一個はやはり、IHE-XDS を基盤としています。患者 X は頻回に旅行するので、それぞれの共同体で診療を受けています。患者 X はロスアンゼルスの病院に「入院しました。受け持ち医は自分の病院の病院情報システムを使用して、この患者に関連する医療情報を複数の共同体に問合せます。いったんデータが発見されると、将来の参照が容易になるように、現場以外の共同体にある患者データへの参照が現場にキャッシュされます。
18.3.2 homeCommunityId 定義
この統合プロファイルでは世界規模で一意の共同体識別子である、homeCommunityId 値を使用して、その共同体内のデータ利用を提供するサービスのウェッブサービス終了点を取得します。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

157

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________



門番役間問合せと登録所保存済問合せトランザクションへの応答の中で返され、応答要素の共同体への関連付けを指示します。書類消費役は応答内の値を無意味（opaque）
固有識別子として処理します。



登録所保存済問合せのオプションのパラメータで、
patient id パラメータを必要とせず、書類セット取得の要求をどの共同体へ送るかを指示します。

発動側門番役が要求を最初にデータが生成された共同体へ送るために使用されます。

18.3.3 詳細な連携
以下の図に、発動側と応答側の両方の門番役が XDS 連携圏にあるときの、すなわち、XDS
連携圏オプションを使用し発動側と応答側の門番役がそれぞれ書類消費役と群化されているときの、実行役間連携の高所からの概観を示します。それぞれの連携についての詳細が図に続きます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

158

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 18.3.3-1: XCA 詳細連携
書類消費役は患者 ID で登録所保存済問合せを発します－書類消費役は患者 ID で登録所保存済問合せを書式化して、最初のトランザクションを開始します。消費役は PDQ, PIX を使用し、あるいはその他の方法を使用し、XDS 連携圏での患者 ID を識別し、この情報とその他の問合せ条件を加えて、登録所保存済問合せ要求を書式化し、発動側門番役に要求を送付します。
発動側門番役は、患者 ID 要求により登録所保存済問合せを処理します－発動側門番役は患者 ID による登録所保存済問合せを受け、以下を決定せねばなりません。a) 要求をどの応
答側門番役に送るか b) 門番間問合せではどの患者 ID を使用するか、です。この段階の詳細な仕様はこのプロファイルの意図の範囲外です。このプロファイルと既存のプロファイ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

159

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

ル（たとえば、PIX/PDQ）、将来のプロファイル、あるいは、設定機構との組み合わせが可能です。既存の PIX/PDQ の使用方法については、ITI TF-2x: E. 10 XCA と患者識別管

理を参照してください。応答したそれぞれの門番役に対して、応答した門番役の共同体に対応する正しい患者識別子で、発動側門番役は問合せを更新して、門番役間問合せを応答
側門番役に対して開始します。発動側門番役が書類消費役と群化されているときには、現場の書類登録所に対して、登録所保存済問合せも開始しなければなりません。
応答側門番役は、患者 ID による登録所保存済問合せを処理します－XDS 連携圏内の応答
側門番役は門番間問合せを、書類消費役と群形成して処理し、現場の書類登録所に対し登録所保存済問合せを始めます。応答側門番役は書類登録所からの応答を更新して、
homeCommunityId が適用されるすべての要素に指定されていることを確認せねばなりません。この更新された応答は門番間問合せへの応答として送られます。
発動側門番役は、患者 ID 応答により門番間問合せを処理します－発動側門番役は接触したすべての応答側門番役からの応答を集めます。集めた応答のそれぞれについて、
homeCommunituId が適切なすべての要素に含まれていることを証明せねばなりません。
もし、発動側門番役が現場の書類登録所に対して登録所保存済問合せトランザクションを始めたなら、このトランザクションに対する応答を更新して、現地共同体のhomeCommunityId 値を含めねばなりません。すべての応答を受けたら、発動側門番役はこれをまとめて書類消費役への一つの応答に仕立てます。発動側門番役は応答側門番役から受けと同じ homeCommunityId 属性値を戻さねばなりません。
書類消費役は、患者 ID 応答により登録所保存済問合せを処理します－書類消費役は発動側門番役から問合せ結果を受け取りますが、応答の二つの固有の面を明らかにせねばなりません。すなわち、a) homeCommnutyId 属性値が指定される、b) 書類消費役は保管庫 ID
値を直接、書類保管庫に対応付けることはできないことがある、です。すべての共同体で使用される、共通のコード・語彙方式が存在せねばなりません。たとえば、すべての共同体は共通のプライバシー同意の語彙を持たねばなりません。書類消費役は、発動側門番役との将来の連携に備え、書類消費役は homeCommunityId 属性を保持せねばなりません。
書類消費役は、UUID による登録所保存済問合せを開始します－多くの登録所保管済み問
合せは患者 ID をパラメータとして含みませんが、代わりに、一般に UUID と言われる、
entryUUID や uniqueID パラメータの一つを要求します。このデータは患者 ID による問合せのメタデータの一部として戻されます。書類消費役は、UUID による問合せの前に患者 ID 問合せを発動側門番役に行うか、その他の方法により正しい homeCommunityID を利用できねばなりません。いずれにせよ、消費役は homeCommunityId 属性をもち、これを問合せのパラメータとして指定できねばなりません。書類消費役は homeCommunityId、
UUID 値、その他の問合せパラメータを登録所保存済問合せのパラメータにいれて、発動側門番役に要求を送らねばなりません。
発動側門番役 は、UUID 要求による登録所保存済問合せを処理します－ 発動側門番役は________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

160

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________UUID による登録所保存済問合せを受け、homeCOmmunityId を使用してどの応答側門番役に接触するかをきめ、応答側門番役のウェッブサービス終了点を取得します。ウェッブ
サービス終了点の取得の手順はこのプロファイルでは特定されません。homeCommunityId
が現場の共同体を示すときは、発動側門番役は現場の書類登録者に対して登録所保存済問合せを始めます。発動側門番役は、応答側門番役に関連する UUID による門番役間問合せの中で、homeCommunityID を指定せねばなりません。
応答側門番役は、UUID による門番役間問合せを処理します－XDS 連携圏内の応答側門番
役は門番間問合せを、書類消費役と群形成して処理し、現場の書類登録所に対し登録所保存済問合せを始めます。門番間問合せの応答には応答側共同体の homeCommunityId を含
まねばなりません。この処理は、患者 ID による門番役間問合せの処理に同じです。
発動側門番役は、UUID 応答による登録所保存済問合せを受けます－UUID 応答による門
番役間問合せの処理は、患者 ID 応答による門番役間問合せの処理に同じですが、一つの違
いは、応答が一個のみのことです。従って、応答のとりまとめは必要ありません。
書類消費役は、UUID 応答による登録所保存済問合せを受けます－UUID 応答による門番
役間問合せの処理は、患者 ID 応答による門番役間問合せの処理に同じです
書類消費役は、書類セット取得を始めます－書類セット取得トランザクションを発する前に、種類消費役は患者 ID による登録所保存済問合せを発動側門番役に送ることがあります。
患者 ID による登録所保存済問合せと、それに続く UUID による登録所保管問合せの応答には、a) 書類の固有 ID b) 保管庫の固有 ID c) homeCommunityId 属性、を含みます。
書類消費役がこの情報を戻すような登録所保存済問合せを発行できないときは、他の方法で情報を得ねばなりません。書類消費役はこの三つのパラメータを、発動側門番役への書類セット取得トランザクションのの中で、指定せねばなりません。
発動側門番役は、書類セット取得を処理します－XDS 連携圏内の応答側門番役は門番役間取得を、書類消費役と群形成して処理し、要求に含まれれる保管庫固有 ID によって特定した書類保管庫に対し、書類セット取得トランザクションを始めます。門番役間取得要求に複数の保管庫固有 ID を含むときは、応答側門番役は複数の書類保管庫に接触し、その応答を一つにまとめねばなりません。

18.4 XCA 安全考慮
18.4.1 XCA リスク分析とリスク評価
XCA のリスク分析には、資産、脅威、軽減策があります。リスクデータの完全な一覧は IHEに保存され、IHE から取得可能です6。

リスク分析データは ftp://ftp.ihe.net/IT_infrastructure/iheitiyr5-2007-2008/Technical_Cmte/Profile_Work/XC/XC
ARiskAnalysi.xls にあります。
6________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

161

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

リスク評価の目的は、XCA 実行役を実装する際、販売者が考慮するよう助言されるリスクのいくつかを知らせることにあります。IHE の一般的なリスクと脅威については、ITI TF-1:
付録 L を参照してください。
多くのリスクは IHE プロファイルでは解決できず、かわりに、軽減策の責任は、販売者、時に連携圏、個々の施設に転嫁されることを、販売者に助言します。この様な場合、IHE は以下の節を使用してリスクを受けた団体に通知して、IHE の責任を果たします。
18.4.2 推奨以下の軽減策はすべての XCA 実行役に実装されねばなりません。これらの軽減策は高衝撃のリスクを軽減します。


M1: すべての XCA 実行役は ATNA 安全拠点実行役（あるいは安全アプリケーション）、
CT 時刻クライアントと一括されねばなりません。



M2: 書類のメタデータは、書類内容の SHA１ハッシュ関数値を含まねばなりません。
アプリケーションは、書類破壊検出の要求があったときには、書類の SHA1 ハッシュ
値をメタデータ内の SHA1 ハッシュ値で証明することができねばなりません。

M3:

書類消費役実装品は、応答データの過剰による過負荷を、ソケットでの読み出しの中止とソケット閉鎖によって、取り扱えねばなりません。発動側と応答側門番役
は、応答の処理を中止して接続遮断に応答せねばなりません。


M4: 書類消費役実装品は、患者を特定しない登所保管済問合せを発行してはなりません。すなわち、患者識別、あるいは、書類エントリ固有 ID を提供せねばなりません。



M6: 不明の患者識別に問合せには、施設の基本方針に従い、空書類のみの情報を戻す
か、XDSUnknownPatientId を戻すか、せねばなりません。これは正しく書式化された識別子にも、不正に書式化された識別子にも適応されます。識別子の書式が不正とのエラーコードを発生しないことにより、アプリケーションのデータをさがす能力を減らすことができます。これは、応答側門番役にあてはまります。



M5: DSG1 統合プロファイルを用いて書類にデジタル署名をすることができます。

以下の軽減策は書類が悪意をもって改竄されるリスクを扱います。この軽減策はオプショ
ンです。


T1:

登録所メタデータ、保管庫の書類、門番役設定のバックアップシステムが推奨さ

れます。


T2:

すべての実装品は、すべての受領データが適切に確実に進む様にする（破壊なしに完成する）か、エラーを提示するよう、推奨されます。


T3:

すべてのサービスインターフェースに対する DoS 攻撃を防御できる程度のネッ

トワーク防御サービスが推奨されます。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

162

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

T5: サービスインターフェースは、破滅と DoS 攻撃の防御ができるように良好にデザインされて実装することが推奨されます。

18.4.3 基本方針の選択
基本方針の選択はこのプロファイルでは扱いません。それぞれの共同体はことなった基本方針を持つことがあります。このプロファイルはこの事実を念頭に置き、基本方針の変動を十分に理解してデザインされましたので、このプロファイルに反することなく、あらゆ
る合理的な基本方針のもとで、実装できます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

163

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

19 基礎患者プライバシ承諾（Basic Patient Privacy Consents, BPPC）統合プロファイル
XD*によりもたらされる書類共有の基盤は患者に関連する臨床書類の公表と使用を可能にします。この統合プロファイルにより、患者プライバシー基本方針連携圏（Patient Privacy
Policy Domain）、たとえば、XDS 連携圏が、承認（「承諾（consent）」とも言う）可能な、多くの患者プライバシ方針を有することができるようになります。これにより、患者の懸念をささえながら、一方で医療提供者に重要で有用な情報を提供する様な、柔軟性を持たせることができます。BPPC が無いときには、XDS 統合プロファイルでは、XDS 連携圏の管理者は単一の書類公表・使用の基本方針（ITI TF-1: 付録 L を見て下さい）を作成し合意します。このような単一 XDS 連携圏基本方針は、XDS 連携圏内のシステムの内在的利用制
御により、分散された様式で補強されます。
このプロファイルでは、ISO 22600－特権管理と利用制限（PMAC）に合致する用語を使用しますが、PMAC を装備するシステムに限定されません。このプロファイルでは、「患者」とは健康関連データの対象であるヒトを言います。この状況では、現に治療を受けている
ヒトに限られないので、時に「消費者」とも言われます。このプロファイルでは「承諾」とは、情報利用基本方針とも言われる、プライバシー基本方針の承認を意味します。この
状況では、プライバシ方針は、制限と義務を含むことがあります。XDS に含まれるシステ
ムは XDS 連携圏の基本方針7を完遂するため十分な利用制限を行う必要があります。
医療提供者は、治療、請求、施設の運用を行うため、データの多くの異なったセットを利用します。この情報には、患者基本情報、連絡先、保険情報、食餌への要求、一般的臨床
情報、機微な臨床情報、が含まれます。この様な情報は独立した書類として、それぞれ異なった機微性（すなわち、秘匿性コード[confidentia]ityCode]）を持って公表（たとえば、
XDS, XDR, XDM, PACS）されます。この機構は BPPC に限られませんが、プライバシと安全基本方針により補強されます。
医療提供者は異なる機能的役割を有するので、このような書類の利用の必要性も異なります。たとえば、管理者は患者基本情報、請求書類、連絡先書類を利用する必要があります。
給食部の職員は食餌の書類を利用する必要がありますが、保険情報を利用する必要はありません。一般医療提供者は大部分の臨床情報を利用したいと思い、直接に診療を提供する者はすべての臨床情報を利用できねばなりません。これは、患者プライバシー基本方針連

7

オンライン出版された、IHE 白書「IHE による HIE 安全とプライバシ」http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Whitepaper_Security_and_Privacy_2007_07_18.
pdf を参照してください。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

164

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

携圏（Patient Privacy Policy Domain）内で患者プライバシ方針識別子を与えられる、患者プライバシー基本方針（Patient Privacy Policy）の例です。患者がこの基本方針を承認
すると、その患者プライバシ方針書類は患者プライバシ識別子で基本方針に参照されます。
このプロファイルは、書類共有について、患者プライバシー基本方針連携圏が管理する患者プライバシ識別子を特定する基本コード語彙の作成を可能とする機構を提供します。それぞれのプライバシ方針識別子は、容認できる使用や再公開使用とは何か、どの機能がどの書類にどのような条件で利用可能か、等を記した法的文書内で特定されるプライバシ方
針を一意に同定します。XDS 連携圏の管理者は、XDS 連携圏内での使用に、それぞれのプ
ライバシ方針識別子を割り付けます。プロファイルは将来、法的文書に加え、より動的に患者の指示を理解できるように使用可能な、同意基本方針の構造化されコード化された表
現を含むことがあります（HL7 や OASIS を見てください）。

19.1 基本患者プライバシ承諾使用例
この節はいくつかの、あり得る患者プラバシ承諾基本方針の例と、書類を公表したり使用するシステムがどのように行動するかとを、記述します。この節は情報的内容で、BPPCの唯一の実装法を記述したものではありません。この節の目的は、BPPC の実装者が BPPC
運用の基本の理解を容易にすることです。
19.1.1 暗黙的承諾と明示的承諾
このプロファイルでは、暗黙的承諾と明示的承諾のいずれも使用可能です。このプロファ
イルが広く受け入れられるため、両者を提案します。暗黙的承諾の環境では、書類消費役
が患者に特異的なプライバシ承諾基本方針の承認の一事例も見いだせないことは正常のことです。プライバシ承諾基本方針を承認する行為の記録は必要ないからです。注: これは、医学的な理由で承諾が遅れる場合（緊急時）では、明示的承諾の環境でも、真です。
XDS 連携圏はプライバシ承諾基本方針を記述した紙の書類を持っていることがあります。
ここでの例では、プライバシ承諾基本方針は、プライバシ方針識別子（たとえば、9.8.7.6.5.4.3.2.1 の様な OID）で管理される現場の XDS 連携圏に与えられます。図 19.1-1に示す例は、ばかげています（ニワトリの衣装）が、これは IHE は基本方針を書かないこと、ヒトが読めるものであれば、この基本方針を補強する様に実行役を設定できる限り、いかなる基本方針も使用できることを強調するためです。この例は、基本方針の内容は見読性のある文書であり、構造化されコード化されたものでないことも強調します。この例
では、基本方針は以下の様になります。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

165

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 19.1-1

基本方針の例

19.1.1.1 オプトイン（承諾後参加）
臨床書類の通常の共有構造では、実際に書類が生成される前に、患者は共有したい旨を承諾します。この場合には、XDS 連携圏の管理者は、何を共有するか、いつ共有するか、いつ使用できるか、等を示した基本方針を書きます。患者が明示的に共有に参加することを選択するまでは書類は共有されないとの XDS 連携圏の上位基本方針があります。
19.1.1.2 オプトアウト（否定後除外）
同様によく見られる共有の構造は、患者が療養を受けることを選択した場合、治療の目的
で自身の書類を正常に共有することを暗黙的に承諾したとするものです。このような環境では、患者が共有に参加しないことを選択できる様な制御が行われます。これは通常、オ
プトアウトと言われます。
この例では、オプトアウトの基本方針の承諾が存在する場合には、書類は共有されないこと、出現する書類は使用してはならないこととなります。XDS 連携圏の管理者は、奇異本方針で実際の振る舞いをどうするかを明確にせねばなりません。
19.1.2 紙署名
XDS 連携圏は患者承諾を紙にインクで書くことにできます。たとえば以下の図です。

図 19-2 単純承諾の例________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

166

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

承諾は、XDS スキャン文書内容プロファイルに従って記録され、BPPC プロファイルで定められたパラメータを持ちます。これは XDS 連携圏に、患者が 9.8.7.6.5.4.3.2.1 の基本方針に承諾した証拠として送られます。
以下にこれを図示します。

図 19.1.2-1 紙署名承諾の図示例
もし、XDS 連携圏がさらに否認不可能な防御を必要とするなら、デジタル署名を、IHE-DSG
プロファイルを使用して、目的と適切な署名システムでの署名をすべてひとまとめにして、適用することもできます。
19.1.3 高度患者プライバシ承諾
XDS 連携圏が法律管轄あるいは組織的な基本方針により、より複雑な患者プライバシ承諾
基本方針を必要とすることがあります。このようなプライバシ方針では、患者が保護された、あるいは、機微な健康情報を特定の目的で公開することを明示的に承諾せねばならないことがあります。BPPC はこのようなタイプのプライバシ承諾の出発点となりますが、基本方針を補強するのに必要な情報を如何に伝達するかは明示しません。このような例では、BPPC の能力はすべての要求を満たすほど大きくはありません。高度患者プライバシ
承諾の例として、患者が自身の書類を利用してよい人物を指名する場合があります。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

167

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

19.2 患者プライバシ方針の作成
患者プライバシ方針圏（たとえば、XDS 連携圏）は、保護された情報の全般的に適切な使用を明確に定義する、患者プライバシ方針圏の全般的基本方針を作成し、公表する必要があります。これは UTI TF-1: 付録 L の主題でここにはこれ以上は記しません。
この患者プライバシ方針圏（たとえば、XDS 連携圏）では、全般的基本方針は患者プライバシ方針の容認できる使用の定義セットです。患者プライバシ方針は患者に選択権を与える様な方法で、保護された情報の適切な使用をさらに説明します。BPPC プロファイルは
このような基本方針に何の要求事項をおきませんし、このような基本方針を作成する方法にも何の要求事項をおきません（このような基本方針の作成に一定のガイドについては、ITI
TF-1: 付録 P を見てください）。BPPC は患者プラ橋基本方針圏は、特定の基本方針のセットから作成できるとしています。ここでは、それぞれの基本方針は独立に、あるいは、特定のタイプの書類の公表と利用の関係にもとづいて組み合わせて、使用できます。

図 19-2.1 患者プライバシ方針階層の例
患者プライバシ方針は、誰が情報を利用できるか、どのような情報を基本方針の対象にするか（たとえば、いかなる条件で書類が機微な情報と印付けられ、どの特定目的で、どの特定職種の個人が使用するか）、を特定します。この基本方針を公表する機構はこのプロフ
ァイルでは記述されません。患者プライバシ方針圏で書かれた患者プライバシ方針のセッ
トは、この圏を利用するあらゆるシステムにある技術で実装可能でなければなりません。
これは、患者プライバシ方針は補強可能であるように、最大の注意をもって作成さればならないことを意味します。
患者プライバシ方針は、患者プライバシ方針識別子として知られる、固有の識別子（OID）
を与えられます。これは患者の特定の患者プライバシ方針の承諾を記録するときに使用され、結果として患者プライバシ方針承諾書類（すなわち BPPC 書類の一事例）となります。
最後に、XDS 連携圏内で使用されるプライバシ承諾基本方針と XDM, XDR プロファイル
でのプライバシ承諾基本方針は、XDM や XDR がその場の要求に応じて書類を転送する時________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

168

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________に使用されるので、異なることが予想されます。患者は、XDS 連携圏内で一般的に共有するのでなく、媒体上の情報を媒体を作成した医療提供者に特定の使用のため共有することを承諾します。XDS 連携圏内で生成した情報を媒体に転送する（XDM）ときには、XDS
連携圏のプライバシ承諾基本方針が公表中に変更されることがあります。さらに、媒体での共有の承諾、XDR で伝送される承諾、XDS 連携圏で共有される承諾に考慮されるべき、情報の機微性にも差があります。詳細はこの巻で後にある安全考慮を見てください。
19.2.1 基本方針作成、公表のまとめ
1.

患者プライバシ方針圏が全般的な基本方針を書き合意します（多くの弁護士がいりま
す）
。

2.

患者プライバシ方針圏は患者プライバシ方針の小さなセットを含みます（もっと多くの弁護士がいります）。これは今日使用されているプライバシ承諾書ときわめて似た文
書です。

3.

患者プライバシ方針は、患者プライバシ方針識別子と呼ばれる、固有の識別子（OID）
を与えられます。

4.

患者プライバシ方針圏の基本方針とすべての患者プライバシ方針は、いずれかの方法で公表されます。これは地域の規制に適合するように公開されます。

5.

患者が患者プライバシ方針を承認したとき、患者プライバシ方針承諾書類が、患者が承諾した基本方針の患者プライバシ方針識別子とともに、公表されます。

19.3 実行役とトランザクション
BPPC には、内容生成役（Content Creator）と内容消費役（Content Consumer）の二つの実行役があります。内容は内容生成役で作成され、内容消費役が消費します。内容の共有や伝達、一つの実行役から他の実行役への更新については、XDS、XDM、および、XDR
での内容結合の節、PCC TF-2: 4.1、に記述の適切な IHE プロファイルの使用により処理されますので、このプロファイルの範囲外です。書類源や可搬媒体生成役は内容消費役を含包することができます。

図 19.3-1: BPPC 実行役図
表 19.3-1 に、BPPC プロファイルに直接含まれる実行役のそれぞれに対するトランザクシ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

169

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

ョンを示します。この統合プロファイルが使用可能と主張するには、必須のトランザクシ
ョン（"R"表記）が実行できねばなりません。"O"表記のトランザクションはオプションです。この統合プロファイルに定められ、実装者が選択可能なオプションの一覧は表 19.3-1にあります。
表 19.3-1: BPPC 統合プロファイル－実行役とトランザクション

19.3.1 群形成
19.3.1.1 XDS, XDR, XDS と結合した基本患者プライバシ承諾
BPPC 内容生成役または内容消費役は、XDS, XDR, XDM プロファイルのうち、適切な実
行役と群形成できます。書類共有、交換通信文で送られるメタデータは特定の関係や依存（結合、binding）を臨床書類の内容に対して持ちます。臨床書類とはこの場合、基本患者
プライバシ承諾書類で、ITI TF-3: 3.5.1.2 と 5.1.3 に記されています。


BPPC 内容生成役は XDS/XDR 書類源、または、および、XDM 可搬媒体生成役と群化されねばなりません（訳者注: 原文には不明な and があります）。



BPPC 内容消費役は、XDS 書類消費役と、および、XDR 書類受領役と、または、XDM
可搬媒体取込み役と群化されねばなりません。

19.3.1.2 基本患者プライバシと XDS-SD との群形成
BPPC 内容消費役は XDS-SD 内容消費役と群化されねばなりません。これは、BPPC の内
容消費役は、XDS-SD 内容も表示できねばならぬことを意味します。これは、（スキャンが）紙署名を記録する普通のやり方だからです。

19.4 基本患者プライバシ承諾プロファイルオプション
この統合プロファイルに選択可能なオプションを、適用される IHE 実行役とともに、表19.4-1 に示します。
表 19.4-1: 基本患者プライバシ承諾－実行役とオプション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

170

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

注 1: 内容生成役は基本患者プライバシ承諾オプションを実装せねばならず、スキャン書類付基本患者プライバシ承諾オプションを選択できます。
注 2: 内容生成役は基本患者プライバシ承諾閲覧オプションを実装せねばなりません。

19.4.1 意図的に空白のままです。
19.4.2 意図的に空白のままです。
19.4.3 基本患者プライバシ承諾オプション
内容生成役は患者プライバシ承諾書類内容を、ITI TF-3: 5.2 節に定められた様に、生成できねばなりません。
患者プライバシ方針承諾書類は一種の医療書類です。患者プライバシ方針承諾書類の内容には、承諾有効期限、患者プライバシ方針圏（たとえば XDS 連携圏）が定義するコード化
語彙で患者プライバシ承諾方針識別子（OID）識別するもの、を含まねばなりません。患者
プライバシ方針承諾書類は、患者が承諾したことの文書による記述を含むことがあります。
患者プライバシ方針承諾は署名できます。使用例に見る様に、内容生成役が DSG 内容生成
役と群化する必要があることがあります。
BPPC プロファイルはこの群形成を要しません。
この群形成は IHE 統合宣言書で完全に記述されます。
19.4.4 スキャン書類付基本患者プライバシ承諾オプション
基本患者プライバシ承諾書類（Basic Patient Privacy Acknowledgement Document）はスキャンされた書類を含むことがあります。スキャン書類の例としては、書面に書かれた患者の紙署名があります。スキャン書類付基本患者プライバシ方針承諾オプションが可能と主張する内容生成役は、ITI TF-3: 5.1.3 で定める様に、スキャン書類内容付患者プライバシ方針承諾を生成できねばなりません。
19.4.5 患者プライバシ承諾閲覧オプション
内容消費役は、患者プライバシ方針承諾書類内容を、ITI TF-3: 5.1.2 と ITI TF-3: 5.1.3 に定める様に、表示できねばなりません。

19.5 意図的に空白のまま
19.6 XDS 連携圏での BPPC 処理流れ
この処理流れは XDS 連携圏が如何に BPPC プロファイルを紙よするかを示します。基本的な処理流れのみが示されますが、このプロファイルは他の処理流れも使用可能とします。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

171

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

19.6.1 プライバシ方針患者承諾のチエック
BPPC に登録された方針を補強する XDS 書類消費役は、特定の患者により承諾された患者
プライバシ方針承諾書類の事例を問い合わせできます。XDS メタデータにより、書類消費
役はどの患者プライバシ方針が承諾されたかを決めることができます。
もし、地域の規制が許すなら、XDS 連携圏は承諾書類を公表しないでいることができるので、XDS 連携圏内に特定の患者の患者プライバシ承諾書類が一切無い（暗黙的承諾）ような設定も扱えるねばならないことに注意してください。
もし、地域の規制が許すなら、一部の患者では承諾が記録される前に書類が共有されることがあることに注意してください。この場合には、XDS 連携圏の方針で、承諾書が無い状
態での振る舞いや既定の振る舞いを説明する必要があります。
19.6.2 患者のプライバシ方針承諾の記録
内容消費役は患者プライバシ方針承諾書類を、スキャン書類があっても無くても、生成します。この書類は、特定の方針の患者による承諾を記録します。
19.6.3 承諾方針に照らしての書類の公表
XDS 連 携 圏 で 管 理 す る す べ て の 書 類 、 XDM/XDR に よ り 転 送 さ れ た 書 類 は 、
confidentialityCode で印付けられます。XDS 連携圏の管理者は、語彙を定義し、語彙に対応する意味を定めねねばならないことがあります。
基本患者プライバシ強制オプションを使用可能とする XDS や XDR 書類源は、どの XDS 連
携圏－プライバシ承諾方針が書類公表を許しているかを決めます。ある種の XDS 連携圏では、患者が特定の方針を承諾したかを調べねばならぬことがあります。
書類源は XDM メタデータ－confidentialityCode－を設定して、（XDS 連携圏の方針で決まる）使用と制限の適切な機微レベルを示します。XDS 書類登録所は、confidentialityCodeのそれぞれが XDS 連携圏内での使用を承認する confidentialityCode の一覧に存在することを証明します。
19.6.4 公表された書類の使用
基本患者プライバシ強制オプションを使用可能とする XDS 書類消費役が XDS 連携圏に問い合わせるときは、登録所保存済クエリの中で confidentialityCode フィルタを利用して、書類消費役が使用できる書類のみを戻されるように制限します。
書類消費役は返送された XDS メタデータ－confidentialityCode にもとづいて、承諾の現状、
システムのタイプ、使用者、状況、その他のシステムが実施可能な因子により、利用制限を実施します。
書類消費役は「承認された」承諾書を問い合わせることができ、結果の XDS メタデータを、現状で承認された患者プライバシ方針承諾書類の一覧として使用することができます。生類消費役システムには患者プライバシ方針承諾書類の内容を取得する必要はありません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

172

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

19.7 安全の考慮
XDS 連携圏に保存された承諾はプライバシ方針によっても統括されます。患者プライバシ
方針承諾書類の内容自身が機微な情報を含むことがあります。たとえば、終末期を迎えた患者が自分の予後を家族に知らせないが他の情報は知らせて良いと決めたとします。患者
プライバシ方針承諾書類を家族と共有すると、予後の悪さが知られてしまう可能性があります。患者プライバシ方針承諾書類に付けられた confidentialityCode は適切に割り付けられねばなりません（たとえば、大部分は最も広い使用の confidentialityCode を割り付けます）。
しかし、未使用媒体に記録された（XDM）患者プライバシ方針承諾書類や XDR で伝達された患者プライバシ方針承諾書類は機微な情報を含んではなりません。その理由は、情報の受け手が、受け手自身の患者プライバシ方針に沿って如何に情報を扱うかを知るため、この情報を共有するのに使用した承諾を読めねばならないからです。
患者プライバシ方針を医療機関の環境内で実装することは、他の治療とは関係のない環境
で利用制限方針を実装することとは、別の考慮とリスクがあります。これは、重要な情報を利用できないようにすると、患者に深刻な障害が出たり死亡したりするリスクがあるためです。このリスクは、私的情報が事故によりあるいは不正な使用により公開された場合の起訴や訴訟のリスクをはかりにかけねばなりません。XDS 連携圏は患者プライバシ方針を書くときは、これを避けるように注意せねばなりません。
医療でしばしば適応される軽減策は、監査制御による説明責任の提供です。これは、医療提供者は私的情報の利用を濫用することは無いと信頼されているからですが、濫用がおきないことを確実にするため、医療提供者の私的情報の利用を監視する方針で、これを後追いで補強します。この戦力は重要な臨床情報の利用が制限されたための死亡や障害のリスクを減らしますが、私的情報の公開のリスクが増えます。これが、ITI 技術委員会が監査追跡と拠点認証（ATNA）統合プロファイルを作成した理由です。さらに、ATNA を XDS とその関連プロファイルに必須とする理由です。
連携圏で解決しなければならない、もう一つのリスクは真に機微な登録所内の情報（たとえば精神病の書類）を共有する問題を如何に処理するかです。推奨可能な一つの戦力は、真に機微な情報は XDS 連携圏内では共有しないことです: XDR や XDM を用いた宛先指定の通信が適切と思われます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

173

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

20 スキャン書類内容の施設間共有統合プロファイル
種々の昔ながらの紙、フィルム、電子あるいはスキャナー出力形式が臨床書類の保存と交換に使用されています。この様な形式は医療の記録用二位亜デザインされていないうえ、
患者識別子、患者基本情報、受診、オーダやサービス情報を含む、書類に関連する医療メ
タデータを保存する一定の機構を持っていません。構造化された医療メタデータとこの様な書類との関連付けは、情報源システムで管理する際に、患者の健康情報の統合性を維持するのに重要です。この元のメタデータを書類とともに保存できるようにする機構が必要です。
このプロファイルは、構造化 HL7 CDA R2 ヘッダの内部で表されるこの様な情報と PDF
あるいは単純テキスト形式の臨床情報を含む書類との対をいかに作る化を定めます。さらに、このプロファイルではこの様な書類に最小限の注釈を付けるに必要な CDA R2 ヘッダの要素を定めます。このヘッダ要素には、患者識別、患者基本情報、スキャナ操作者の識別、スキャン技術、スキャン日時および手にいる限りの編集情報に関する情報を含みます。
CDA R2 ヘッダの一部は、追加の書類登録情報とともに、XDS 書類エントリのメタデータに値を入れるのに使用されます。
このプロファイルの内容は XDS、XDR、および、XDM で使用する様に意図されています。
内容は内容生成役で生成され、内容消費役に利用されます。内容生成役は書類源または可搬媒体生成役に取り込まれ、内容消費役は書類消費役、書類受領役、あるいは、可搬媒体
取り込み役に取り込まれます。このプロファイルが内容生成役と内容消費役に課す義務は、
スキャン技術で言うよりは、提出用に最終書類を生成する、および・あるいは、プロファ
イルに合致する書類を消費する、ソフトウェアで遂行されると理解されます。

20.1 使用例
20.1.1 内容使用例
文字と図のノート
この内容の例には、手書きの、タイプされた、あるいはワープロで書かれた書類、および・
または図のノートです。この様な書類は、通常、多ページの口述文書です。事前に印刷された用紙に手書きで字をいれたもの、印刷された書類、タイプあるいはワープロで作成された書類で、種々の形式で保存された書類、です。適切な形式はワープロ形式から作られた PDF、あるいは、伝達するのが文字構造のみなら単純テキストです。ワープロで書かれた書類内容を最も忠実に変換すること、非文字注釈に込められた意味を保持するため、PDFが望ましいです。
グラフ、図、および・または、線画例としては、成長グラフ、胎児モニタグラフ、上記の線画で、PDF を使用して最良に変換されますが、
JPEG の様な圧縮画像も対抗としてあります。生成した PDF が線を含むとき、あるいは非可逆圧縮は診断目的には受け入れらず、PDF を使うべきです。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

174

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

光学認識（OCR）されたスキャン書類
臨床書類は、OCR では完全に処理できない文字や注釈を含み得ます。OCR 文書内容は書類内容の一部を表現できるのみであることを注意します。これは PDF への変換で最もよく表現できます。PDF は OCR 文書、圧縮された書類、スキャンされた画像領域の混合も可能
です。
電子化書類
既存の電子的に転送されたか、ソフトウェアで精査された臨床書類（たとえば、PDF、単純テキスト）は、実スキャン、既往スキャン、仮想的スキャン、にわけて考えられます。
実スキャンとは、昔ながらの紙やフィルムからある種のスキャン技術で共有を目的に新たに生成されたものです。既往スキャンとは、昔ながらの紙やフィルムからある種のスキャン技術で以前に生成された電子書類ですが、一定時間存在するものです。仮想的スキャン
電子書類とは、既存の電子書類で昔ながらの紙やフィルムから生成されたものでない、
PDF/A または単純テキストか、あるいは、共有のためこの形式に変換されたものです。こ
の内容はこのプロファイルで扱います。
20.1.2 内容生成使用例
内容は内容生成役で生成されます。アプリケーションと業務流れへの影響は実装に依りますが、この統合プロファイルの範囲外です。CDA 包含 PDF や CDA 包含単純テキスト、あるいはこの両者を生成可能なアプリケーションはこのプロファイルに合致することに注意
してください。以下の使用例はこの内容プロファイルを眺める助けとなるように、含まれています。
Legacy 診療所は小さな医者 2 名の診療所です。現状では、患者の医療情報は紙に記録し保存しています。電子化システムに移行するため、診療所はこの紙記録とワープロ文書をどうするか理解しようとしています。このファイルを現場のイントラネット上で閲覧したいと思っています。
現状では、大部分の記録は印刷された用紙に手書きされ、患者カルテの特定の部位に挿入されています。より詳細な診療記録は口述され、口述筆記会社に送られ、ワープロ形
式の書類として戻ってきます。Legacy 診療所の医療記録事務員がこのファイルを e-mailで受け取り、暗号解読し、印刷し、患者カルテの正しい場所に加えます。
Legacy 診療所は、何年も異なった口述筆記会社を使用してきましたので、書類は様々な
ワープロ形式で保存されています。一致していないワープロ形式を取り扱う不便をへらす試みとして、数年前、診療所は返送される書類に RTF 形式を要求し始めました。ほんの一部の例で患者と診察メタデータが、当時使用していた口述筆記会社に依存して、規則的な形式でワープロ書類内に保存されました。第 3 者が現在、検査室を診療所のために指揮しています。これらは印刷された書類として診療所に戻されます。事務員はこれを患者カルテの検査部に印刷された書類として挿入します。
Legacy 診療所の例では、現有の手作業処理が連携を維持していること、および、一部の________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

175

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

ファイルは診察のメタデータを保持していることのため、ワープロで生成された書類と患者の連携は書類の多くで維持されています。しかし、特定の診察との連携は、書類内容をみて再確立せねばなりませんが、連携を持たない一部の書類では多大な労力を要します。さらに、このメタデータを保存するのに使用する形式によっては特別の取り扱いを要します。
Legacy 診療所は、CDA 第 2 版ヘッダ包含の PDF 書類を生成できる口述筆記提供業者をいまは使用しています。これは e-mail で Legacy 診療書へ送られます。
（診療所では保存に）同じ手作業が行われますが、この書類はいまでは新しい HER システムですぐに使用できる形式です。
20.1.3 内容消費役使用例
内容は名愛用消費役に利用されます。アプリケーションと業務流れへの影響は実装に依り
ますが、この統合プロファイルの範囲外です。しかしながら、このプロファイルの採用には内容消費役は書類を受けたら、CDA 包含 PDF や CDA 包含単純テキストの両者の処理を可能とする必要があることに注意してください。

20.2 実行役とトランザクション
XDS-SD プロファイルには、内容生成役と内容消費役のふたつの実行役があります。内容
は内容生成役が作り、内容消費役が利用します。一つの実行役から他の実行役への内容の共有や伝達は以下に記す IHE プロファイルを適切に使用して処理されますが、このプロフ
ァイルの範囲外です。書類源や可搬媒体生成役は、内容生成役をなかにとりこむことができます。書類消費役、書類受領役、あるいは可搬媒体取り込み役は、内容消費役をなかに取り込むことができます。一つの実行役から他の実行役への内容の共有や伝達、あるいは更新は「XDS、XDM、XDR との内容結合」の節に記されています。
図 20.2-1 にスキャン書類内容統合プロファイルに直接含まれる実行役と実行役間の関連するトランザクションを示します。他の統合プロファイルに参加するため、間接的に含まれる他の実行役はかならずしも示されていません。

図 20.2-1: スキャン書類実行役図20.3 スキャン書類内容統合プロファイルオプション
スキャン書類のオプションは患者療養協働（PCC）テクニカルフレームワークのオプションに影響します。表 20.3-1 に、この統合プロファイルに選択可能なオプションを、適用さ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

176

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

れる実行役とともに、示します。
表 20.3-1: XDS-SD－実行役とオプション

注 1: 実行役はこれらのオプションの少なくとも一つを使用可能とせねばなりません。

20.4 スキャン画像 XDS、XDR、XDM 結合
ITI XDS、XDM あるいは XDR プロファイルは、この統合プロファイルの共有機能を取り込んでいます。内容生成役あるいは内容消費役は XDS、XDM あるいは XDR プロファイルからの適切な実行役と群形成されて、内容を交換します。書類共有あるいは交換通信文のなかで送信されたメタデータは内容プロファイルに記述された臨床書類の内容と特定の関係や依存関係（これを結合と呼びます）を持ちます。患者療養協働テクニカルフレームワーク（PCC-TF）は、このプロファイルの内容生成役と IHE ITI XDS、XDM あるいは XDR
統合プロファイルからの実行役と群形成するときは、結合を使用するよう定めています。
PC-TF-2: 4 を参照してください。

20.5 スキャン処理内容処理流れ
このプロファイルは XDS-SD を生成するときには、以下の一連の事例を想定しています。
1.

昔ながらの紙の書類はスキャンされ、PDF/A が生成されます。かわりに、電子ファイルが必要なら、PDF/A あるいは単純テキスト形式に変換されます（ITI TF-3: 5.2.1 と5.2.1.1 をみてください）。

2.

このプロファイルに適合するソフトウェアとおそらく使用者からの入力（たとえば、書類のタイトル、秘匿コード、元の著者を入れる）が PDF あるいは単純テキストに関係する cda 第 2 版ヘッダを生成します。書類は包含され、XDS-SD が完成します（ITI
TF-3: 5.2.3 をみてください）。

3.

XDS メタデータが CDA ヘッダに含まれるデータと追加情報からから生成されます（ITI TF-3: 5.2.2 をみてください）。

4.

完成した XDS-SD 文書と対応するメタデータは、書類セット提供と登録トランザクシ
ョン[ITI-15]あるいは XDS/XDR の[ITI-41]、あるいは、XDM の書類セット媒体配布ト
ランザクション[ITI-32]を経由して、送信します。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

177

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

21 値セット共有統合プロファイル（SVS）
値セット共有(SVS)プロファイルは臨床あるいは管理データを生成する医療システムが、画像診断装置、検査レポートシステム、総合診療医診察室 EMR システム、国の医療情報シス
テム、などが、中央で管理される共通の、一定した用語を受けられる手段を提供します。
用語の共有は意味の相互運用性には不可欠です。
一個の値セット保管庫は多くの値消費役に利用可能で、一貫した一定の用語のセットからなる領域を形成します。これは、値消費役による自動的な値セット積み込みを可能とし用
手設定による負荷を軽減します。このプロファイルは、値セット消費役による値セット保管庫からのデータ取得の二つの方法を記述します。


一個の値の値セットは OID 値にもとづいて取得できます。これは特定の値を使用する
様予め設定されたシステムの要求に応えることを目指したものです。このようなシステムとしては、厳密に制御された機能を持つ医療用具で十分な検討無しに機能を変えることができ無いものです。このトランザクションにはメタデータを含まず、要求で一意に識別されている値セット一覧の構想を提供します。



多値の値セットは値セットのメタデータに基づいて取得できます。これは、値セットを動的に選択するシステムや使用者の必要に応えることを目指したもので、どの値セッ
トを使用すべきか決めたり、既存の値セットの構想に基づき新しい値セットを生成します。このトランザクションでは、より豊富な選択基準が使用可能で、メタデータの記述とこの選択基準に合致するすべての値セットの内容（コード化値の拡張された一覧）を提供します。

いずれのトランザクションも、メタデータを割り付けられた、グループ識別子を含む、中央化された値セットの利用を提供します。値セットのグループの識別能力は意味的な相互運用性の達成と電子健康録（EHR）の組み立てセット構造の開発に不可欠です。グループ
識別は、たとえば、ある種のレポートを埋めるような任意の目的のため、すべての値セッ
トを識別するのに使用できます。

21.1 実行役・トランザクション
図 21.1-1 に SVS 統合プロファイル直接に含まれる実行役と、それらの間の関連するトランザクションを示します。他の関連するプロファイルに参加するため、間接的にこのプロフ
ァイルに含まれる他の実行役は必ずしも示されません。同様に、値セットを生成する方法
はこのプロファイルには含まれるたません。
（この問題は基盤が整備され次第、あつかわれ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

178

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________ます）。

表 21.1-1: SVS 統合プロファイル－実行役とトランザクションには、SVS プロファイルに直接含まれる実行役のそれぞれに対するトランザクションを示します。この統合プロファ
イルが使用可能であると主張するには、実装品は必須のトランザクション（"R"表記）を実
行せねばなりません。"O"と表記されたトランザクションはオプションです。この統合プロファイルに定められたオプションの完全な一覧は表 21.2-1 にあります。
表 21.2-1: SVS 統合プロファイル－実行役とトランザクション

21.1.1 前提と背景情報
値セットは有効な構想の表示の一意のセットです。値セットは、一個のコ－ド化方式から引用された構想のコードの単純な一覧であるか、複数のコード化システムから引用された表示からなることもあります（コ－ド化システムは名称と意味からなるシステムで、たとえば、LOINC, SNOMED-CT, ICD-10 あるいは ISO 639 言語コ－ドです）。
このプロファイルは構想の単純な一覧を扱います。が、もっとも単純な値セットの例は表21.1.1-1：カナダの州に示します。
表 21.1.1-1:カナダの州________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

179

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

21.1.1.2 値セットの ID と値セットの版
値セットは、種々のアプリケーションや使用者が認識できる様に、一意に識別されねばな
りません。値セットが取得されたとき、アプリケーションや使用者はその一事例、あるいは、拡張値セット（Expanded Value Set は、特定の時に有効な、値セット定義の特定の版の構想の表示）を取得することになります。値セットと拡張値セットの構想は、プログラ
ム構想の、Class と Instance of Class の構想に似ています。
このプロファイルでは値セット ID（Value Set Unique ID、ISO IOD を用いる）と値セッ
ト版（Value Set Version）属性を使用して、値セットの識別の柔軟な取扱を可能にします。
値セットのこの定義から導かれた実際のコードセットは、拡張値セットです。SVS は二つの異なった識別方法で拡張値セットの共有を可能とします。
1.

拡張値セット自身の固有識別子を用い、それを生成した定義を参照しません。このような拡張値セットは自身の固有識別子（すなわち、OID と版）を持ち運びます。

2.

拡張値セットを導き出した値セット定義への参照を用います。この場合、拡張値セッ
ト（同じ値セット定義から導きされています）はその拡張日付と時刻で区別されます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

180

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 21.1.2-1: 値セット識別の二つの方法
21.1.3 IT SVS と CTS の関係
値セット保管庫は、HL7 CTS あるいは来るべき HL7 CTS2 仕様を使用している術語サー
バを実装するシステム で使用可能です。HL7 CTS, CTS2 仕様と統合プロファイルの相補的役割に注意することが重要です。
CTS は術語管理サービスが可能とする API（Application
Programming Interface）を定めます。CTS2 は術語管理サービスが可能とする機能を定め
ますが、API の仕様は対象物管理グループに任せます。 SVS は、特に焦点を値セットの配布に絞って、術語サーバのネットワーク利用の通信プロトコルを定めます。
しかし、SVS、CTS・CTS2 の間には、機能的な一貫性があります。より正確には、同じ主体については、値セットの全属性と、共有値セット取得トランザクションに記述の構想とは、CTS・CTS2 の機能仕様に定められた属性の部分セットです。SVS は、複数のコード
システム（たとえば、DICOM, SNOMED）からの構想を含む値セットの配布が可能であることに注意してください。これは CTS の能力に合致しますが、CTS 仕様には記されていません（CTS2 には記述されています）。
情報提供の参考：
1.

LexGrid Common Termiology Services
http://informatics.mayo.edu/LexFrid/downloads/CTC/specifications/ctsspec/cts.htm

2.

Common Terminology Service 2 (CTS 2). Sevice Function Model Specification. (最新の情報については HL7 のホームページをみてください

21.1.3.1 値セット配布業務流れ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

181

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________SVS トランザクションでは三種類の値セットが使用可能です。
1.

意図的値セットは計算論理あるいはその他の方法の面から定義されています。この値
セットは値セット保管庫が使用可能ですが、このプロファイルでは表形式での伝達の手段を提供しません。代わりにこの値セットはメタデータを使用して記述され、適切な拡張値セット内容が、意図的値セット定義と拡張メタデータとともに、返されます。
このプロファイルでは、多値セット取得トランザクション[ITI-60]を使用してこのデー
タを如何に取得するかが定められています。

2.

拡張的値セットは構想の一致欄表の面から定義されています。意図的値セットと同様に、値セットの定義と拡張メタデータが、適切な拡張値セット内容と一緒に、取得可
能です。このプロファイルでは、多値セット取得トランザクション[ITI-60]を使用してこのデータを如何に取得するかが定められています。

3.

拡張値セットは、値セット定義（意図的および拡張値セット）からの拡張の結果です
が、そのメタデータは値セット消費役には重要でなく、特異的語彙からの特異的コードの一覧で定められた、特定事例が共有されます。このプロファイルでは、多値セッ
ト取得トランザクション[ITI-60]または値セット取得トランザクション[ITI-48]を使用
してこのデータを如何に取得するかが定められています。

値セットの開発者はこの様なタイプの一個以上を選択できますが、値セットの最終消費者
は拡張値セットが作業するのに必要です。意図的および拡張的値セットの明示的定義を交換する標準的方法を開発する努力が進行中ですが、SVS 統合プロファイルの範囲外です。
SVS は拡張された値セットを配布する方法を提供するのみです。
SVS プロファイルは拡張値セットの複雑性を制限します。現状では、コード化された術語からのコードの構造化されていない一覧のみを使用可能としています。他の内部構造、たとえば、階層は定義されていません。これは、全部ではありませんが大部分の値セットの必要を満たします。
このプロファイルでは、値セットの拡張に関連する処理と規則は、特定も制限もされていません。適切な拡張を行うことは、値セットの開発者あるいは、SVS 保管庫を支えるシス
テムの責任です。値セット開発者が値セットの拡張形式に標準的配布形式を定めた場合には、開発者はこの拡張に適切な手順を有しています。値セット開発者が拡張された値セッ
ト様式を配布する手順を持たない場合は、SVS プロファイルを使用するには、これを確立する必要があります。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

182

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 21.1.31-1: 値セット開発ながれ
拡張値セットをを定義し公表する値セット開発者は、この値セット、あるいはこの拡張値セットを結果として生成する定義のいずれかを、識別する識別子も樹立せねばなりません。
値セットを記述するメタデータも定義します。（値セットグループの記述は後に議論します。）メタデータは以下に一覧で示しますが、記述情報、追加説明へのリンク、有効期日、等を含みます。SVS プロファイル拡張値セットを取得する二つのトランザクションを提供
します：
1.

値セット取得－これは拡張値セットの迅速な取得に適しています。値セットを必要とするシステムにあらかじめ設定されている値セットの OID 有することにもとづき
拡張値セットを取得します。このトランザクションでは拡張値セットのメタデータも値セット定義のメタデータも、取得しません。
2.

多値セット取得－

これは、メタデータ内容にもとづいて値セットを取得するのに________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

183

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

適しています。これは、値セット OID にもとづいて値セットを取得できますが、内容
記述、OID と版、日付、などにもとづいて値セット拡張を取得することもできます。
この取得様式は、取得した値セットの拡張値セット内容と値セットのメタデータの両方を提供します。
意図的および拡張的値セット値を公表する値セット開発者は、値セットの定義に OID を定めます。開発者は関連する複数の値セットの様式を複数公表することがあり、それぞれの様式に適切な OID を割り付けます。SVS を公表するときには、値セット開発者は、提供されるべき拡張様式を、メタデータとともに提供せねばなりません。SVS プロファイルは意
図的およぼ拡張的値セットを取得する一個のトランザクションを提供します。
複数値セットの取得 － これは、値セット OID を含むメタデータ内容に基づいて値セッ
トを取得するのに適していますが、記述、グループ名、日付などの内容にもとづくこともできます。この方式の取得では、取得する値セットの拡張値セット内容と値セットのメタ
データの両方を提供します。意図的および拡張的値セットの定義する標準様式を定める他の労力ががあることに注意してください。この様な他の様式は、値セット開発者による仕様を意図したものでう。SVS プロファイルは主に値セット使用者に拡張様式を提供します。
意図的あるいは拡張的値セットを受けとる値セット使用者は、拡張は単に提示目的の使用のみのためであることに留意してください。有効期限、記述材料の様な、他のメタデータ
は拡張様式の正しい使用をきめる際には相談せねばなりません。実際は、値セットは寛恕にしか変化せす、拡張様式の使用に際して人が閲覧して拡張様式の使用について決定する
時間が通常あります。
SVS プロファイルではこの拡張を如何に、何時、行うべきかを定めていません。これは値セット開発者やサーバ維持管理者の責任です。多くの場合、値セット開発者は、拡張様式と共に有効期限を提供し、参加している組織が変更を容易に管理できるようにします。

図 21.1.3.1-2: SVS 取得トランザクション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

184

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

21.11.3.2 値セットグループ
値セットは、グループ形成や印付け機構で記述されます。このグループ化は多くの異なった組織で並列に規定されることがあります。それぞれの組織はそれ自身の目的でグループを作成すると思われます。ある組織は”H1N1 に関連する値セット”のようなグループ分けしますが、一方、他の組織は“臨床治験 xyz 報告書関連の値セット”のようにグループ分けします。第３の組織は”H1N1 インフルエンザ治療の処方集”とします。それぞれのっそしき
はキーワードを割り付けて、取得要求で関連するグループが見つけられるようにし、このグループに OID を割り付けます。
維持を簡単にするため、SVS はそれぞれの組織のキーワードやグループを組み合わせて一個の一覧表とするよりも、それぞれの値セットに関連付けるグループ記述の一覧表を定めます。グループのキーワードやグループの OID にもとづき取得を行うとき、取得トラ案ザクションはこの記述の全てを検索します。
新しいグループを作成する組織は、そのグループ分けの目的にあわせ、キーワードと OIDの一覧表を定義できます。このグループ記述は、このグループの一員でならねばならない
個々の値セットに添付できます。値セットをグループから削除する必要があるときは、添付された記述は削除できます。これにより、複数の組織が同じキーワードを使用する時に、キーワードを誤って削除するのを避けられます。

図 21.1.3.2-1: 値セットのグループ記述
21.1.3.3 値セット記述メタデータ
表 21.1.3.3-1 に示すデータ野に含まれるメタデータで値セットは記述されます。メタデー
タのコード化については、ITI-2b:3.60 を参照してください。表にデータ野の必須とオプシ
ョンの別が示されています。メタデータの一部は ITI-48 と ITI-60 両方のトランザクション
で取得条件にできますし、一部は ITI-60 のみが使用できますし、さらに一部は両方とも取________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

185

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

得条件にできません。
表 21.1.3.3-1: 亜田尾セットメタデータ要約

このメタデータのデータ野の一部は、多値セット取得の選択条件に指定できます。使用可
能なメタデータは多値セット取得の結果として戻されます。ITI-48 トランザクションではメタデータは戻されません。
このプロファイルでは値セットを以下の維持するか、新しい値セットを如何に加えるか、既存の値セットを如何に更新するかを定めません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

186

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

21.2 SVS 統合プロファイルオプション
この統合プロファイルに選択可能なオプションを表 21.2-1「値セットの共有－実行役とオプション」に、適用される実行役とともに示します。オプションの間の依存は注に記されます。値セット消費役は表のオプションの二つの結合の少なくとも一個を実装瀬鍋ならないことに注意してください。値セット保管庫は ITI TF-2b:3.48.5 に示される様に、両方の結合を実装せねばなりません。
表 21.2-1: 値セットの共有－実行役とオプション

21.2.1 多値セットの取得
多値セット取得オプションを使用可能とする値セット消費役と保管庫は、多値セット取得
トランザクション[ITI-60]を使用可能とせねばありません。

21.3 SVS 処理流れ
この節は、値セット消費役が値セット保管庫から値セットを取得するときの処理と情報の流れを記述します。二つの間に必須の順番はありません。値セット消費役はいずれのトラ
ンザクションを選んでよく、順番は適宜です。値セット消費役は既知の値セット OID に基づいて、一個の値セットを取得します。多値セット取得[ITI-60]トランザクションが、選択条件に合致する値セットの全てを取得するのに使用できます。ITI-60 の選択条件は既知の値セット OID を含む必要はありません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

187

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図21.3-1: SVS プロファイルの基本処理流れ

21.3.1 流れ全体の概観
このプロファイルは値セットの生成と管理に含まれると予想される実行役の大きなシステ
ム状況での機能を記述します。
値セットの生成はこのプロファイルの範囲外です。このプロファイルの基盤が実現した後に、扱われます。定義の目的では、値セットの生成はコードシステムから値セットを生成すること、あるいは、使用者が自身のシステムで使用する使用者提案値を持つこと、です。
完全な処理は下記の、図 21.3.1-1「処理流れ概観」に、明確化のため、示します。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

188

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 21.3.1-1: 処理流れ概観
図 21.3.1-1 に値セットの生成と管理に含まれると予想される実行役の大きなシステム状況
での、値セット取得トランザクションを示します。
SVS プロファイルは部分的に意味的相互運用性の問題を解決しますが、値セットの使用に必要な状況を提供する構造がすでに実現していると想定されています。
構造の提示はこのプロファイルの範囲外ですが、意味的相互運用性を達成するため重要な役割を果たすことが認識されねばなりません。このプロファイルの焦点は、適切な意味的内容をもつ情報モデルを広めるため、一般的で均一な命名を配布することです。
21.3.2 使用例
以下の使用例は、このプロファイルが種々の専門領域で如何に使用できるか示します。
注：

使用例にある全ての表は単なる例です。IHE はこの表を更新する責任を有しません。

21.3.2.1 XDS 連携圏に一貫した命名の配布
一貫した命名は、classCode, confidentialityCode, eventCodeList,
heealthcareFacilityTypeCode, practiceSettingCode, eventCode の様な、XDS 連携圏のメ
タデータ要素で必須です。より詳細な情報は、ihe.net の IHE IT Infrastructure TechnicalCommittee White Paper – Template for XDS Affinity Domain Deployment Planning にあります。
21.3.2.1.1 現状________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

189

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

連携圏で使用される命名は、システムに用手的に入力されます。時間のかかる作業で誤ることもあります。
21.3.2.1.2 望むべき状況
それぞれのアプリケーションは値セット保管庫から XDS 連携圏で必要な値セットを取得し、用手的入力を無くし、正確性を増します。
21.3.2.2 システム間での医療、請求コードの術語更新
標準的なコード化は健康保険プログラムで請求が順序だった一貫した処理が行われることを確実にします。
CPT は、公的あるいは私的健康保険プログラムの請求のための、記述用語と識別コードからなる均一な、医師や医療専門家（HCP）が行う医療サービスや処置を識別することに主に使用される、コードシステムです。
21.3.2.2.1 現状
患者は彼女の PCP により小さな医療施設から大きな医療施設へ紹介されます。彼女は入院し、医療専門家のグループ：腫瘍医、検査技師、薬剤師、看護士、で見られます。
患者記録には、電子医療録（EMR）、検査情報システム(LIS)、放射線情報システムの様な、異なる医療情報の境界システムからの情報を含んでいます。
全てのシステムは、コード化された情報の切れ目無い情報の流れが実現する様に、最新のCPT コードを必要とします。現状では更新はシッステムごとにアプリケーションに特異な方法で行われており、複数システムで値セットを更新する際のエラーのリスクを増やします。
病院で作成される退院要約は統一した一貫した命名が無いため、受けた療養についてのコード化された情報が欠落しています。書類は地域の保管庫に出版されるか、可搬媒体に保存されます。PCP はその情報を（たとえば、XDS, XDM を用いて）取得できます。
コード化の欠損のため、二つの望ましくない結末が起こりえます。：正しい請求が支払者に届かない、あるいは、医学情報が機械で処理できないため他のシステムに組み込めず、データ検索が困難になります。
21.3.2.2.2 望まれる状況
病院は値セット保管庫から、有意の CPT コードを受け取り、全てのアプリケーションが同じ名称を使える様になります。この様にして、医学と請求情報が継ぎ目無く流れ、医療の質を向上させます。
21.3.2.3 画像での対部位名の一貫したコード化
21.3.2.3.1 現状
A 病院では撮影技師が CT 検査を始めようとしています。技師はプロトコルを選択し撮影部位を推測して、装置にある「撮影部位」データ野に用手的に値を入れねばなりません。撮影装置は、RIS が CT 検査に与えた設定を上書きします（あるいあ、装置販売者や実装のあり方にしたがい、既存の RIS 情報を使います）。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

190

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

検査は A 医療施設の現場 PACS に送信され、検査目録が XDS 保管庫 B に送られます。B
病院は XDS 登録所に問い合わせてこの検査を取得したいと思います。
あるいは、患者は A 病院の検査を CD に記録して IRWF を使用して B 病院の現場システムに読み込みます。
A 病院の RIS が体部位に使用する名称は B 病院の RIS が選んだコード化と一貫していません。現場の PACS と RIS 管理役は RIS にオーダを用手入力して同じ対部位名を使って検査の一貫性を持たせ、放射線科医が定まった画像表示方式で観察できるようにします。
21.3.2.3.2 望ましい状況
A 病院では撮影技師が CT 検査を始めようとしています。技師はの最新の体部位値セットを
値セット保管庫からダウンロードして正しい「体部位」を選びます。検査は医療施設 A の
現場 PACS に送信され、検査目録が XDS 保管庫 A に送られます。B 病院は XDS 登録所に問い合わせてこの検査を取得したいと思います。
あるいは、患者は A 病院の検査を CD に記録して IRWF を使用して B 病院の現場システムに読み込みます。B 病院も同じ拡張値セットを値セット保管庫からダウンロードしたので、A 病院の RIS で選んだ体部位は B 病院の RIS で選んだものと同じです。放射線科医は自分の部門で定まった画像表示方式で観察できるようになります。
この様な目的に使用できる一覧表値のセットは、DICOM Part 16, CID 4031 共通解剖部位
で、その抄録は表 21.3.2.3.2-1; CID 4031 共通解剖部位にあります。
表 21.3.2.3.2-1: CID 4031 共通解剖部位

注：Context ID 4031 共通解剖部位の抄録、タイプ：拡張可能、Version 20061023, DICOM Part 16, OID
1.2.840.100008.6.1.308.

2.1.3.2.4 乳房撮影のプロトコルコードの変更________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

191

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

放射線科や医療施設は現場の方針と業務流れに従って使用注のシステムで共通に使用される現場コードを定めます。


放射線テクニカルフレームワークからの乳房撮影業務流れ（MAWF）プロファイルに従い、



コードが以下に対して使用されます：



検査予定と実行時の振る舞い（要求検査、要求検査理由、予定プロトコル）



画像と業務進捗状態の記録：実行済検査、実行済プロトコル、観察方向、などのコードは既定の表示方式で掲示できる様になります。



放射線スタッフが実行された業務を追跡し、正しい課金コードを選択できる様になります。

MAWF プロファイルはさらに、部門や医療施設は全てのシステムで共通に使用できるコー
ドセットを定め、それぞれのコードセットが同じ有効な内容のまま全システムで使用可能であるようにと、述べています。それぞれのシステムはどのコードセットを使用するかを設定できる必要があります。コードセット配布の共通機構の欠如により、の様な技師や医師には理解できる「通常スクリーニング」、「拡大」、「CAD」の様な現場限りのプロトコルの策定に結びつきますが、これは、他の部門や医療施設には適用できず、自動エラー訂正の面では撮影機器には理解できません。
さらに、この様なコードは変更、削除、旧式との認定、単に欠落の目にあいます。RIS のプロトコルコード一覧が完全には信頼できないため、この様な状況は混乱を招きます。

予定業務流れプロファイルや乳房撮影業務流れプロファイルで定義された技術的意味にか
かわらず、使用者やシッステムの振る舞いの変動のため、部門業務の非効率、あいまいデータ、自動請求の例外、至適とは言えない撮影および読影環境に結びつきます。
21.3.2.4.1 現状
患者は予定の通常のスクリーング乳房撮影に来ました。撮影が進むうち、怪しい腫瘤が検出されました。追加の撮影が必要となり、技師が撮影しました。予定された通常のスクリーニング撮影の代わり、診断乳房撮影が行われます。この情報は RIS に通信され請求コードを変更し、暗黙的に読影時の放射線科医への掲示方式を変更します。この様に、技師は用手的に検査を変更せねばなりません。
検査コードは RIS の検査後変更で訂正され、表示と課金のため、正しい情報が記録されます。
21.3.2.4.2 望まれる状況
検査コードの変更は撮影装置で直接に行なわれ、エラー、誤解、矛盾を生成する可能性のある介在が避けられます。SVS プロファイルでは、中央化された専用の拡張値セットを利用する機構を提供します。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

192

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

乳房撮影専用の拡張値セットコードが値セット保管庫から使用可能になります。
撮影装置は値セット消費役として働き、乳房撮影に共通して使用され定義された拡張値セットを取得します。
正しい検査タイプが処理されます（あるいは、少なくとも技師が一覧表から正しい項目を選択できる様になります）。
表 21.3.2.4.2-1: 乳房撮影コード

注：これは、
例として使用される、暫定値で、DICOM 標準への組み込みが現在要望されています（RAD TF-1:
B.2 ZA を参照）
。この表の更新には IHE は責任を負いません。

表 21.3.2.4.2-2: 要求検査理由のコード________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

193

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

注 1: この値は DICOM CID 6061 (DICOM PS 3.16)に由来します。
注 2：これは暫定値で、DICOM 標準への組み込みが現在要望されています（RADTF-1: B.2 ZA を参照）
。この表の更新には IHE は責任を負いません。
21.3.2.5 SOD と他のマスタ源からの値セットの配布
術後の使用者、コード、および、値セットの一方とし、標準作成組織（SOD）と他の術後開発者、コード、と値セットを他方とする、両方向性関係があります。以下の図に、術後と値セットの、値セット消費役への流れの処理を示します。使用者のコメントや新しい要求が情報源に逆流してきます。
図の最上部で、値セット消費役はマスタ値セット保管庫から、特定の目的に必要な値セットを取得します。特定の目的で特定の OID 値を持つように消費役が設定されている時は、
ITI-48 トランザクションで実行できます。しばしば特定の種類の報告書に値を入れるため全ての値セットが必要な場合の様に、共通の目的をもつ一群の値セットを取得する必要があります。これは ITI-60 多値セット取得トランザクションを使用して実行できます。
このマスタ値セット保管庫は、閲覧と統制の下にあります。個別の消費役は協調組織にマ
スタ値セット保管庫を管理し維持する責任を委任します。これは典型的には標準術語の開発者ではありません。マスタ保管庫組織は管理役あるいは協調役として働き、SOD から出される標準術語が、値セット消費者の日常業務を邪魔することのない様に確認します。これは新しい術語や値セットの要求を協調させます。この活動を両方向性に協調する統率委員会がああります。この協調は、マスタ値セット保管庫の維持に重要です。プロファイルの一部としてはこれ以上記載しません。
術語開発者は典型的には新しい術語と値セットを定期的予定にもとづき、あるいは、処理に合わせた時点で発行します。この通知は掲示板、電子的通知、その他の方法で行われます。これはこのプロファイルの一部には含まれません。SOD がその配布過程の一部として値セット保管庫を設立するならば、統率委員会は ITI-60 を SOD 値セットのコピーを取得する方法として選ぶことができます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

194

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 21.3.2.5-1: 使用者と値セットの開発者との関係
21.3.2.6 メタデータにもとづく値セットの取得
電子メール、掲示板、などの通知が特定の OID でなく、記述的内容を含む状況がしばしばあります。同様に、記述のみに基づいて有用な値セットを見つけねばならないこともあります。この様な使用の例は：
1.

使用者が米国連合委員会からの脳卒中療養測定の値セットの全てを必要としています。
この測定はグループ名に“卒中”を含むことで識別されます。使用者は今年生成され________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

195

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

たデータを扱う決定支援および分析アプリケーションのきっかけを作る出発点としてこれを使用する計画があります。
1.

“卒中”を含むグループを有する値セット、“連合委員会”を含む源、あるいは“JCAHO”を含む源で今年有効な値セットを要求するため、値セット消費薬と相互作用します。

2.

値セット保管庫はは全ての一致する値セットを見つけ、全ての値セットとそれを記述するメタデータを含む応答を送ります。ヨーロッパ連合委員会も存在するため、応答には余分なデータも含まれます。

3.

目的に関係のないデータを除外するため完全なメタデータをクライアントを使用します。

21.4 SVS 安全考慮
SVS プロファイルが扱う内容は患者特異的ではないので、プライバシのリスクはありません。一部の拡張値セットは、非重要情報の公衆に公開された表（たとえば、医療検査に使う、体部位をコード化する拡張値セット）であるため、攻撃者にはほとんど価値がありません。他の拡張値セットは悪意ある変更やかすめ取りから守るため防御が必要かもしれま
せん。
SVS プロファイルに当てはまるリスクは“SVS プロファイルに関連するリスク”の表で議論 さ れ て い ま す 。 こ れ は 、

IHE

の

FTP

サ イ ト 、

ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr6-2008-2009/Technical_Cmte/Profile_Work/Sh
aringValueSets/を見てください。拡張値セット交換の本質が、引き起こす可能性のあるタ
イプとリスクを決めます。たとえば、なりすましの様な統合性リスク8や、拡張値セットの改造のリスクがあり得ます。他の可能なタイプのリスクとしては、秘匿データを含む拡張
値セットのかすめ取りの様なプライバシや秘匿レベルです。このプロファイルはこの様なリスクを以下の様に必要なときには軽減します。


値セット保管庫は ATNA 安全拠点、あるいは、安全アプリケーションと群化されねばなりません。値セット消費役は、TNA 安全拠点、あるいは、安全アプリケーションと群化する必要はないので、値セット保管庫は、安全および、非安全接続の両方を使用可能にせねばなりません。



値セット保管庫は特定の拡張値セットの利用を、認証され権威付けられた教典に制限し、一方で認証されていない別の拡張値セットへの問い合わせは可能にせねばなりません。



拡張値セットを要求するシステムの多様性を考えると、このプロファイルは値セット
消費役に ATNA 安全拠点あるいは安全」アプリケーションとの群化を必須とはしませ8

値セット保管庫につながる悪意あるサーバで、ねつ造されたデータ値を与えます。
________________________________________________________________________________

Rev. 10.0 Final Text – 2013-09-27

196

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

ん。現場のリスク評価や現場の方針によってはこの様な群化が必須とされることがあります。

22 書類依拠紹介要求統合（Document-based Referral Request, DPR）プロファ
イル
このプロファイルは、施設間書類業務流れ（Cross-Enterprise Document Wokrflow, XDW）の使用を優先するため、引退しました。

23 患者識別相互参照 HL7 V3（PIXV3）
患者識別相互参照 HL7 V3 統合プロファイル（PIXV3）は施設間患者識別圏（ITI TF-1: 5で定義）と同じく、先進の IT 基盤を有する医療施設に向けたものです。参照されるトラン
ザクションの明白な調整を伴いますが、ITI TF-1: 5 の論議がすべて当てはまります。

図 23-1: 患者識別相互参照 HL7 V3 の処理流れ

23.1 実行役・トランザクション
このプロファイルの実行役は PIX 往路ファイルで定義されたものと同じです（ITI TF-1:
5.1）。図 23-1 に患者識別相互参照 HL7 V3 に直接含まれる実行役と、実行役間の関連するトランザクションを示します。他の関連するプロファイルに参加するため間接的に含まれる実行役は示されていません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

197

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

図 23-1: 患者識別相互参照 HL7 V3 実行役図
表 23.1-1 に患者識別相互参照に直接含まれる実行役のそれぞれに対するトランザクションを示します。この統合プロファイルが使用可能と主張するには、実装品は必須のトランザクション（”R”と表記）を実行できねばなりません。”O”と表記されたトランザクションはオプションです。この統合プロファイルに定義され、実装者が選択可能なオプションの完全な一覧は ITI TF-1: 23.2 にあります。
表 23.1-1: 患者識別相互参照 HL7 V3 統合プロファイル－実行役とトランザクション

このプロファイルのトランザクションは PIX プロファイル（ITI TF-1: 5）で使用されるトランザクションに直接対応し、同じ機能を提供します。表 23.1-2 にこの対応を記述します。
表 23.1-2: PIX と PIXV3 プロファイル間のトランザクションの対応

23.2 患者識別相互参照 HL7 V3 統合プロファイルオプション
表 23.2-1 に、この統合プロファイルに選択可能なオプションを適用される実行役とともに、示します。
表 23.2-1: 患者識別相互参照 HL7 V3 統合プロファイル－実行役とオプション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

198

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

23.2.1 小児基本情報
予防接種登録や他の公衆衛生データベースの経験から、同一人に対する複数の異なった情報源から、小児の記録が多くを占める環境で、患者記録を対応させ連携させるには、追加の基本情報が必要であることがわかっています。
特に、双子、三つ子の様な場合の記録の区別－偽りの対応付けの回避－は、基本情報の多くが二人の間で同じなため、困難なことがあります。たとえば、双子では同じ、姓、親、
住所、誕生日；名も似通って、一文字しか違わないことがあります。コンピュータはもちろん、人間の目でみても、名のわずかの違いが、単なる書き間違いか、二人の異なった記
録か、決めかねることがあります。この決定には追加の情報がきわめて重要です。
小児基本情報は以下の六個の追加基本情報データ野を使用し、多くの小児記録のデータベースで記録の対応付けを助けます。

小児基本情報オプションを使用可能とする患者識別源実行役は、患者識別管理[ITI-30]トラ
ンザクションを使用可能とせねばならず、もし値が使用可能なら、小児基本情報データ野として識別されるデータ野に値を入れねばなりません。
小児基本情報オプションを使用可能とする患者識別相互参照管理役は患者識別管理[ITI-30]トランザクションを使用可能とせねばなりません。もし、小児基本情報データ野の________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

199

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

一個以上に患者識別管理[ITI-30]で値が特定されている場合には、この値を PIX 管理役は対応付け計算の一部として考慮ねばなりません。
小児基本情報は、以下の全てと定められています。


母の旧姓名



患者の家庭電話番号

患者多胎指標



患者生誕順



最終更新日付・時刻



最終更新施設小児基本情報は特に二つのデータ問題に焦点を置いています:23.3 患者識別相互参照 HL7 V3 統合プロファイル処理流れ
ITI TF-1: 5.3.1 と ITI TF-1: 5.3.2 にこの統合プロファイルがあるか合う使用例があります。
図 5.3-1 と図 5.3-2 は、表 23.1-2 に特定されている様に対応する、PIXV3 トランザクショ
ンへの変更にも適応されます。

23.4 PIXV3 統合プロファイルと eMPI との関係
ITI TF-1: 5.4 の議論はこのプロファイルにすべて当てはまります。

23.5 患者識別子通信要求事項
HL7 V3 通信文内の患者識別子は IIg 型データで表されています。このデータ型は二つの要素を持っています: ルートと拡張です。HL7 V2 通信文を使用するプロファイルでの患者識別子の使用法との適合性のため、および、XDS プロファイルでの患者識別子の仕様により、患者識別子はルートと拡張とっで表現されねばなりません。ルートは適切に割り付けられた OID です。II データ型と HL7 2.5 版 CX データ型（PID-3 データ野で使用）との直接の対応については、ITI TF-2x: 付録 R に示されています。

23.6 安全の考慮
このプロファイルの実装者には、多くのリスクは IHE プロファイルでは軽減できず、軽減策の責任は販売者、ときに運用環境に転嫁されることを助言しておきます。
同定された安全リスクを処理するには:

PIXV3 のすべての実行役は時刻一貫性（Consistent Time）プロファイル－時刻クライ
アントと群化されねばなりません。この群形成により、監査記録に時刻スタンプの一貫性を保証する一貫した時計をすべてのシステムに保証します。



PIXV3 のすべての実行役は、監査追跡と拠点認証（ATNA）プロファイル－安全拠点
あるいは ATNA 安全アプリケーションと群化されねばなりません。この群形成により、高度に信頼されたシステムのみが通信でき、全ての変更は監査記録に書かれる様、保証されます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

200

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________PIXV3 のすべての実行役は、XUA X サービス使用者あるいは、X サービス提供者と適切に群化されねばなりません。この群形成により、サービス側の利用制限とより詳細な監査記録を可能にします。



PIXV3 のすべての実行役は、施設使用者認証（EUA）プロファイルからの適切な実行役と群化されねばなりません。この群形成により、施設内では一回の認証で複数の装置やソフトウェアを使用できる様になります。

24 患者基本情報問い合わせHL7 V3 （PDQV3)

患者基本情報問い合わせ HL7 V3 統合プロファイル（PDQV3）は、複数の分散されたアプ
リケーションが、使用者が指定した検索条件で、患者情報サーバに患者一覧を問い合わせる方法を提供し、患者の基本情報を直接アプリケーションに取り込みます。参照されるト
ランザクションの明白な調整を伴いますが、ITI TF-1: 8 の論議がすべて当てはまります。

24.1 実行役・トランザクション
このプロファイルの実行役は PDQ プロファイルで定義されたものと同じです（ITI TF-1:
8.1）。
表 24.1-1: 患者基本情報問い合わせ HL V3 統合プロファイル－実行役とトランザクション
このプロファイルのトランザクションは PDQ プロファイル（ITI TF-1: 8）で使用されるトランザクションに直接対応し、同じ機能を提供します。表 24.1-2 にこの対応を記述します。PDQ プロファイルと異なり、患者基本情報と来院問い合わせ（ITI-22）はありません。
表 24.1-2: PDQ と PDQV3 プロファイル間のトランザクションの対応

24.2 患者基本情報問い合わせ HL7 V3 統合プロファイルオプション
表 24.2-1 に、この統合プロファイルに選択可能なオプションを適用される実行役とともに、示します。オプションの間の依存関係は、適用可能な場合には、注に記されます。
表 24.2-1: 患者識別相互参照 HL7 V3 統合プロファイル－実行役とオプション

継続のサポートはトランザクション ITI-47 に記述されています。このオプションは患者基________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

201

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

本情報消費役が、一回の応答で取得することと反対に、数回にわけてすべての応答を取得することを可能にします。
（訳者注: この 3 行は 24.2.1 節にかかれるべきものと思われます。
）
24.2.1 継続
継続のサポートはトランザクション ITI-47 に記述されています。このオプションは患者基
本情報消費役が、一回の応答で取得することと反対に、数回にわけてすべての応答を取得することを可能にします。
24.2.2 小児基本情報
予防接種登録や他の公衆衛生データベースの経験から、同一人に対する複数の異なった情報源から、小児の記録が多くを占める環境で、患者記録を対応させ連携させるには、追加の基本情報が必要であることがわかっています。
特に、双子、三つ子の様な場合の記録の区別－偽りの対応付けの回避－は、基本情報の多くが二人の間で同じなため、困難なことがあります。たとえば、双子では同じ、姓、親、
住所、誕生日；名も似通って、一文字しか違わないことがあります。コンピュータはもちろん、人間の目でみても、名のわずかの違いが、単なる書き間違いか、二人の異なった記
録か、決めかねることがあります。この決定には追加の情報がきわめて重要です。
小児基本情報は以下の六個の追加基本情報データ野を使用し、多くの小児記録のデータベースで記録の対応付けを助けます。

小児基本情報オプションを使用可能とする患者識別源実行役は、患者識別管理[ITI-30]トラ
ンザクションを使用可能とせねばならず、もし値が使用可能なら、小児基本情報データ野として識別されるデータ野に値を入れねばなりません。
小児基本情報オプションを使用可能とする患者識別相互参照管理役は患者識別管理________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

202

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________[ITI-30]トランザクションを使用可能とせねばなりません。もし、小児基本情報データ野の一個以上に患者識別管理[ITI-30]で値が特定されている場合には、PIX 管理役は、この値を対応付け計算の一部として考慮せねばなりません。
小児基本情報は、以下の全てと定められています。


母の旧姓名



患者の家庭電話番号

患者多胎指標



患者生誕順



最終更新日付・時刻



最終更新施設24.3 患者基本情報問い合わせ HL7 V3 統合プロファイル処理流れ
ITI TF-1: 8.3 にこの統合プロファイルが処理する使用例があります。図 8.3-1 は、このプロファイルに対応のない ITI-22 トランザクションを除いて、表 24.1-2 に特定されている様に対応する、PDQV3 トランザクションへの変更にも適応されます。
24.3.1 PDQV3 と他の IHE 業務流れプロファイルとの組み合わせ使用
ITI TF-1: 8.3.1 での議論に加え、このプロファイルでトランザクション内での輸送としてウェッブサービスを使用すると、XDS.b や PIXV3 の様なウェッブサービス基盤の他のプロファイルが使用される場合に、よく適したものとなります。
24.3.2 供給者データ設定
患者基本情報提供役は問い合わせのパラメータに一致しうる記録についての基本情報を提供します。ITI TF-2x: 付録 M に記述された様に、供給役は複数の（患者 ID）圏からの基
本情報を所有可能ですが、供給役は一組のみの基本情報を返さねばなりません。
供給役が一個の患者 ID 圏の情報を所有する場合、供給役はその圏からの基本情報を提供せねばなりません。供給役が複数の患者 ID 圏からの基本情報を所有している場合、どの基本情報を返すかは、受領側装置の ID 値と、問い合わせ転送包含体の組織階級（HL7 2.5 版対応通信文の MSH-5 と MSH-6 相当）に基づかねばなりません。

24.4 意図的に空白のまま
24.5 安全考慮
このプロファイルの実装者には、多くのリスクは IHE プロファイルでは軽減できず、軽減策の責任は販売者、ときに運用環境に転嫁されることを助言しておきます。
同定された安全リスクを処理するには:

PDQV3 のすべての実行役は時刻一貫性（Consistent Time）プロファイル－時刻クライアントと群化されねばなりません。この群形成により、監査記録に時刻スタンプの一貫性を保証する一貫した時計をすべてのシステムに保証します。



PDQV3 のすべての実行役は、監査追跡と拠点認証（ATNA）プロファイル－安全拠点________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

203

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

あるいは ATNA 安全アプリケーションと群化されねばなりません。この群形成により、高度に信頼されたシステムのみが通信でき、全ての変更は監査記録に書かれる様、保証されます。


PDQV3 のすべての実行役は、XUA X サービス使用者あるいは、X サービス提供者と適切に群化されねばなりません。この群形成により、サービス側の利用制限とより詳
細な監査記録を可能にします。



PDQV3 のすべての実行役は、施設使用者認証（EUA）プロファイルからの適切な実行役と群化されねばなりません。この群形成により、施設内では一人一回の認証で複数の装置やソフトウェアを使用できる様になります。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

204

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

25 多患者問い合わせ（MPQ）
多患者問い合わせ統合プロファイルは、データ分析の分野で必要な、たとえば医療実践者
や医療機関の品質保証、臨床治験データ収集、人口の健康監視、あるいは、ある条件に基づく書類登録所への集合された問い合わせを可能とする機構を定めます。

25.1 実行役・トランザクション
図 25-1 に一つのみの XDS 連携圏内の MPQ 統合プロファイルに直接含まれる実行役と、実行役間の関連するトランザクションを示します。他の関連するプロファイルに参加する
ため間接的に含まれる実行役は必ずしも示されていません。

図 25.1-1: 多患者問い合わせ実行役図
表 25.1-1 に多患者問い合わせプロファイルに直接含まれる実行役のそれぞれに対するトラ
ンザクションを示します。この統合プロファイルが使用可能と主張するには、実装品は必須のトランザクション（”R”と表記）を実行できねばなりません。”O”と表記されたトランザクションはオプションです。この統合プロファイルに定義され、実装者が選択可能なオプションの完全な一覧は ITI TF-1: 25.2 にあります。
表 25.1-1: 多患者問い合わせ統合プロファイル－実行役とトランザクション

25.2 多患者問い合わせ統合プロファイルオプション
表 25.2-1 に、この統合プロファイルに選択可能なオプションを適用される実行役とともに、示します。オプション間の依存は、適用されるときには、注に記されます。
表 25.2-1: 多患者問い合わせ－実行役とオプション________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

205

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

25.2.2 非同期ウェッブサービス交換オプション
このオプションを使用可能とする実行役は以下を使用可能とせねばなりません:1.

書類消費役は非同期ウェッブサービス交換を多患者保存済問い合わせ[ITI-51]トランザクションで使用可能とせねばなりません。

2.

書類登録所は非同期ウェッブサービス交換を多患者保存済問い合わせ[ITI-51]トランザクションで使用可能とせねばなりません。

同期あるいは非同期ウェッブサービス交換の使用は、個別の設置状況と方針により定められます。非同期ウェッブサービス交換の説明は、ITI TF-2X: V. 5 同期および非同期ウェッブサービス交換を参照してください。

25.3 MPQ 処理流れ
この節は、書類消費役が書類登録所に問い合わせる際の、処理と情報の流れを記述します。

図 25.3-1: 多患者問い合わせプロファイルでの基本処理流れ

25.4 使用例
25.4.1 公衆衛生での多患者問い合わせ
現状
A 病院の救急科では B 患者をある症状で治療していますが、その症状はすでに確立した公衆衛生当局からのガイドラインに従うと報告可能な状態（たとえば A1H1(型インフルエンザ)）です。症状により XDS メタデータの既定値セット eventCodeList の使用が必須となります。これは、eventCodeList と観察結果、たとえば、“インフルエンザ”、“A1H1 疑い”と組み合わせることができます。A 病院はこの情報を記録する、退院時要約、救急科診療記録（EDES）、より広い意味ではこの目的のためと意図した書類の様な、どのタイプの書類であっても、
XDS.b 提供と登録トランザクションを用いて現場の XDS.b 登録所に送ります。
同時に、この追補の範囲外の方法で、P 公衆衛生当局に報告書を送ります。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

206

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

報告書を見た後、P 公衆衛生当局は、最近の同様症状での患者診察を閲覧する必要があると決めます。残念ながら、XDS 書類登録所は、現状の患者保存済問合せトランザクションで定められている様に、患者を特定した問い合わせにしか応じません。P 公衆衛生当局は、医療提供者から適切な症状をもつ患者の一覧を取得する必要があります。
A 病院は現場の書類登録書に同じ事例コードを有する書類エントリを問い合わせます。一回の操作で複数の患者を問い合わせることは不可能なので、書類登録所が知っている患者のそれぞれに問い合わせを行います。これは非常に時間のかかることで、正確でないこともあります。
望ましい状況
A 病院の救急科では B 患者をある症状で治療していますが、その症状はすでに確立した公衆衛生当局からのガイドラインに従うと報告可能な状態（たとえば A1H1(型インフルエンザ)）です。症状により XDS メタデータの既定値セット eventCodeList の使用が必須となります。これは、eventCodeList と観察結果、たとえば、“インフルエンザ”、“A1H1 疑い”と組み合わせることができます。A 病院はこの情報を記録する、退院時要約、救急科診療記録（EDES）、より広い意味ではこの目的のためと意図した書類の様な、どのタイプの書類であっても、
XDS.b 提供と登録トランザクションを用いて現場の XDS.b 登録所に送ります。
同時に、この追補の範囲外の方法で、P 公衆衛生当局に報告書を送ります。
報告書を見た後、P 公衆衛生当局は、最近の同様症状での患者診察を閲覧する必要があると決めます。医療提供者は、多患者問合せを用いて、eventCodeList XDS メタデータに同じ既定値をもつ全ての書類を、適切な時期に正確に、P 公衆衛生当局に提供できます。公衆衛生当局は適切な対応を始めることができ、従って、A1H1 の流行の可能性のある事態を阻止できます。
25.4.1.1 事後および、準実時間報告
データを集積して一定の類型をあぶり出す必要がありますが、患者の識別を知る必要まではないことがあります。たとえば、CVC（Center for Disease Control and Prevention）やフランスでは InVS が、ある一時点に国レベルで A1H1 患者が何人知るか知りたいと思ったとします。この場合、患者の識別の必要は全くなく、他のデータも傾向を知る（たとえば年齢）に必要ない場合、ObjectRefst 問い合わせを用いた、メタデータの eventCodeList
を集積問い合わせすれば十分です。この場合、データは傾向を示すため統計的に使用されるため、非可逆的偽名化や匿名化が使用できます。これは、安全とプライバシについての最も単純な実装方針の例です。
準実時間での統計解析が望まれる、インフルエンザ流行の際し地域レベルで特徴抽出を行
うための集積問いあわせの様な、他の場合があります。ここも、患者の識別は必要ないが、症例数とおそらく日付の様なある種のパラメータが必要な状況です。集積問い合わせ尾を________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

207

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

行うためには、HIPAA の推奨に従って、最小限のデータセットであるべきです。
25.4.1.2 詳細問い合わせ患者安全（FDA に薬品、医療器具、あるいは外科手技に関連する患者安全の問題、あるいは、流行時の実時間制御の様な、より高い安全が必要な場合、詳細問い合わせが使用できます（訳者注: “）”が余分です）。保存済問合せの中で LeafClass が特定されている場合、書類のメタデータあるいはフォルダ（書類 ID と保管庫 ID を含む）が返されます。方針に従い、このデータは偽名化されたり、されなかったりします。
多患者問合せの詳細使用は、必要に応じ、患者プライバシの方針は異なります。
25.4.2 技術的使用例
多患者問合せの出力は、二つの形式のうちの一つにできます: （一つは）無意味識別子の一
覧です。それぞれの識別子は検索条件に一致する書類（問い合わせの対象は書類エントリ
でフォルダや提出書類セットではありません）を同定します。；（他の一つは）メタデータ
からわかる全ての詳細である、完全メタデータです。
25.4.2.1 無意味識別子
無意味識別子は、XDS では ObjectRefs として知られますが、以下の様に有用です: 登録所に問い合わせに合致するものが何件あるかを見つけることと、一致する登録所内容物の完全なメタデータを後に取得することです。統計（件数）のみを知る必要のあるアプリケー
ションは返された識別子の数を数えることができます。この識別子は問合せに合致する（たとえば）書類であり、患者ではありません。一人の患者が複数の問い合わせに合致する書類を持つことができます。
25.4.2.2 完全メタデータ
多患者問合せは、XDS では LeadfClass として知られる、完全なメタデータを返すことができます。このメタデータは複数の感謝からの患者 ID、患者基本情報を含み、防御することが難しいとはいえ、防御せねばなりません。この様な機微な情報であるため、この様なタイプの返答結果は高度の親鸞性を持つシステムによってのみ許され、この問い合わせは
他の問い合わせの様に広く利用可能であってはならないと思われます。

25.5 安全考慮
このプロファイルは、典型的な XDS で知られたリスクから防御するため同様な ATNA との群化が当てはまります。このプロファイルは、XUA と群化することができ、結果の使用者の認証をできる様にします。
このプロファアイルでは一回の問合せが一回のトランザクションで済み、複数患者の XDS
メタデータが返されるので、新しい安全とプライバシの考慮が引き起こされます。XDS メ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

208

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

タデータは高度の健康情報ではありませんが、識別可能な健康情報であるので、保護される必要があります。同じ結果のなかに複数患者の保護されるべき情報の組み合わせがあることで、意図した使用に必要な全ての認証を、意図した受領者が有していることを確認す
る困難な業務が結果として生じました。元々の XDS 問合せでは問合せ要求と応答は一人の患者に制限されており、利用制限の決定はトランザクション全体にわたって行うことができます。
このプロファイルでは二つのタイプの応答結果が可能です。ObjectRefs 結果は、結果は単に検索条件に合致する無意味識別子のみを返すので、情報の曝露を限定することができます。この結果はより広範に使用されると期待されています。書類消費役は完全なメタデー
タを取得できますが、対象物一個ずつに対して元々の XDS 問い合わせを使用せねばなりませんので、一人の患者に制限されたトランザクションのみが使用可能です。メタデータを取得する追加のトランザクションのセットは、問い合わせを実行するシステムが LeafClass応答を使用できる様に権威付けられているなら、不要のことがあります。たとえば、問い合わせを行うシステムが情報を同じ程度まで防御するシステムとして知られている場合です。この場合、この問い合わせシステムが適切な利用制限を、究極の使用や公開の前に課します。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

209

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

26 予約済み________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

210

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

211

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

付録 A:

実行役の説明実行役は、施設の運用活動と関連する情報を、生成、管理、あるいは、作用する情報シス
テムまたは、情報システムの一要素です。以下は、IHE IT 基盤統合プロファイルで使用される実行役の定義です。
監査保管庫（Audit Repository） － この実行役は監査記録の保管庫役を提供します。監
査保管庫にどのような分析や報告機能が実装されるべきかは IHE は指定しません。
クライアント認証代理役（Client Authentication Agent）－ 使用者認証の現場管理役を提供します。
状況管理役（Context Manager）－ある状況に参加する 2 個以上の実行役（患者状況参加
役あるいは使用者状況参加役）の間の周旋役として働きます。
表示役（Display）－ 情報源に特定の情報や書類を要求し、それを表示するシステム
書類源（Document Source）－ 書類源実行役は、書類の生成と公表を行います。これは、書類保管庫に書類を送る責任があります、さらに、書類保管庫に書類のメタデータを提供
して、次いで、書類登録書に書類を登録します。
書類消費役（Document Consumer）－ 書類消費役はある基準を満たすメタデータを問合せ、選択された書類を取得します。
書類受領役（Document Recipient）－ 他の実行役が送信した書類セットを受け取ります。
典型的には、この書類セットは、閲覧、あるいは、健康記録に組み込むかを選択する意図をもつ受け手に対し、使用可能とされます。
書類登録所（Document Registry）－ 書類エントリ内の登録済書類のそれぞれについてメ
タデータを保持します。これには、書類が保管された場所を示す保管庫へのリンクが含まれます。書類登録所は、特定の基準を満たす書類の書類消費役からの問合せに応答します。
これは同時に、書類登録時に医療施設に特異な技術的方針を強制します。
書類保管庫（Document Repository）－ 書類保管庫は書類の永続的保存と、適切な書類登
録所への登録の両方に責任があります。書類消費役による後の取得のために、書類に URIを割り付けます。
DNS サーバ（DNS Server）－ この実行役は権威ある場所情報を有しています。
用紙記述役（Form Filler）－ 用紙管理役から用紙を取得し、用紙受領役に用紙の一事例
データを提出する責任を持ちます。用紙記述役はオプションで用紙管理役から説明書を取得する責任があります。
用紙管理役（Form Manager）－ 用紙の識別を提供する要求にもとづいて用紙を提供する実行役です。用紙管理役は説明書情報も提供します。
用紙受領役（Form Receiver）－ 用紙の一事例データを受け取る実行役です。
用紙保管庫（Form Archive）－ 用紙の一事例データを保管のため受け取る責任のある実行役です。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

212

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

発動側門番役（Initiating Gateway）－ 外に出て行く共同体間の通信を可能にします。
情報源（Inforamtion Source）－ 特定の情報や書類の要求に応え、すぐに提示可能な情報を、要求を出した実行役上に表示するため返すシステムです。
Kerberos 認証サーバ（Kerbereos Authentication Server） － 施設内使用者の認証を与える中枢です。
Kerberos 化サーバ（Keroberized Server） －使用者認証情報を、この実行役を含むサービスが行う高度の使用に際して、使用者認証情報を受け取ります。
Patient Context Participant（患者状況参加役）－ 患者状況の設定と、状況管理役により通信された状況変更への対応、との両者による共有状況環境へこの実行役が参加します。、
患者基本情報消費役（Patient Demographics Consumer） － 患者について患者基本情報
供給役から提供された基本情報を使用するシステム。
患者基本情報供給役（Patient Demographics Supplier） －患者と患者関係者（介護者、保証人、隣人など）の基本情報を追加、更新、および維持する責任をもつシステムです。
患者基本情報消費役に、更新された新しい基本情報を提供します。、
患者受診情報源（Patient Encounter Source）－患者の受診情報を、追加、更新、および維持する責任をもつシステムです。患者受診情報消費役に、更新された新しい受診情報を提供します。
患者受診情報消費役（Patient Encounter Consumer）－患者受診情報源から提供された受診情報を使用するシステムです。
患者識別相互参照消費役（Patient Identifier Cross-reference Consumer）－この実行役は、
患者識別圏内のシステムが、患者識別相互参照管理役のサービスを使用して、他の患者識別圏内の患者を同定することができるようにします。
患者識別相互参照管理役（Patient Identifier Cross-reference Manager）－患者識別圏の明確に定義されたセットを供給します。患者識別源実行役により提供されたそれぞれの患者識別圏で与えられた情報に基づき、患者識別圏を越えて患者識別子の相互参照を管理します。
患者識別源（Patient Identity Source）－患者識別源は、それぞれの患者の固有識別子を提供し、識別上の特徴の集合を維持する役です。患者識別圏のそれぞれには、患者識別子を個人に割り付け、他の実行役（たとえば、患者識別相互参照管理役や書類登録所実行役）にすべての患者識別に関する事象（生成、更新、融合）を通知するためには、この実行役が必須です。
職員録消費役（Personnel White Pages Consumer）－この実行役は職員録索引で見つけられる情報を使用します。
職員録索引（Personnel White Pages Directory）－この実行役は施設の職員についての信頼でき権威ある職員録情報を有しています。
可搬媒体生成役（Portable Media Creater）－この実行役は媒体の内容をあつめ、物理的媒________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

213

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

体に書き込みます。既存のこの書類セットは、電子健康録、個人健康録から抽出された者です。
可搬媒体取込み役（Portable Media Importer）－この実行役は媒体に存在する情報を読み、表示し、使用者が選択し、内容物の要素や全部を保存できるようにします。典型的にはこの書類は電子健康録や個人健康記録に統合され、その事例を処理できます。
応答側門番役（Rsponding Gateway） － 入ってくるすべての共同体間通信を使用可能とします。
安全アプリケーション（Secure Application）－この実行役は、安全拠点の一部で、安全のための機能（使用者認証、安全通信、安全監査記録、安全方針強制）が、IHE 統合宣言書の中に同定できる製品（たとえば Web アプリケーション）を含むのに必要ですが、拠点全体を必ずしも含む必要はありません。
安全拠点（Secure Node）－この実行役がシステムに存在すると、その他の実行役や非 IHE
ソフトウェアが IHE の、使用者認証、安全通信、安全監査記録と安全方針の規則に合致するようにできます。
時刻クライアント（Time Client）－は NTO プロトコルに加え、NTP または SNTP アルゴ
リズムのいずれか一方を使用して、１個以上の時刻サーバにより時刻同期を達成します。
現場のコンピュータシステム時計の同期を、時刻サーバとの同期に基づいて、維持します。
時刻サーバ（Time Server） － は時刻クライアントに NTP 時刻サービスを供給します。
使用者状況参加役－ は使用者状況変更通知を受けそれを含むアプリケーションについて変更に従います。
X-サービス供給役（X-Server Provider）－ X 使用者特定を必要とするサービスを提供する
システム
X-サービス使用役（X-service User）－ X サービス提供者のサービス要求を作成するシス
テム________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

214

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

付録 B:

トランザクションの説明

トランザクションは標準に依拠した通信文により要求された情報を伝達する実行役の間の相互作用です。以下は、IHE で定義されたトランザクションの短い説明です。
1.

時刻維持（Maitain Time）: 時刻同期を維持するための NTP トランザクション

2.

使用者認証取得（Get User atuthentication）: 認証代理人クライアントが Kerberos
認証サーバから使用者認証を要求します。使用者が認証されると、Kerberos 認証サー
バは、意向の活動を最適化するため、切符発行許可切符（Ticket Granting TIcket, TGT）
を発行します。

3.

サーバチケット取得（Get Service Ticket）: サービスと一緒に使う Kerberos プロトコルを使用する切符を取得します。

4.

ケルベロス暗号化通信（Kerberized Communication）: ケルベロス暗号化通信トラン
ザクションは現地クライアントと遠隔地サーバとの接続の一面です。

5.

状況参加（Join Context）: 状況参加役が状況管理役を見つけ、これと通信を樹立できるようにします。

6.

状況変更（Change Context）: 状況変更のトランザクションを開始し終了させるのに必要なすべての通信文をふくみます。

7.



先導する参加役からの状況変更要求を開始します。



先導する参加役に、調査結果を届け、関連する応答を表示します

状況管理役に状況変更の決定を通信します。

状況退出（Leave Context）: 状況参加役が状況管理役に、通信を断つことを通知します。

8.

患者識別送付（Patient Identity Feed）: 患者識別供給役が患者識別に関するすべての事例（生成、更新、融合、など）を患者識別相互参照管理役に通知できるようにします。

9.

PIX 問い合わせ（PIX Query）: 患者識別相互参照消費焼くが、患者識別相互参照管理
役のサービスを使用して異なった患者識別圏内にある一人の患者識別情報を見つけることができます。

10. PIX 更新通知: 患者識別相互参照消費役が、それが関心を持つ患者識別圏内の全ての患者の識別情報の変更を、患者識別相互参照管理役から通知される様にできます。
11. 表示用特定情報取得: 即時表示可能な提示形式で戻される、ある患者に関連する特定情報取得の、表示システムが発行した要求のことです。
12. 表示用書類取得: 表示システムは、情報源が守る一意に識別された永続的書類の一次例を要求し、その内容を即時表示可能な提示形式で受け取ります。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

215

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

13. 状況追従: 応答する参加役に状況の変更を流布するのに必要な全ての通信文を考慮します。


状況管理役による全ての状況参加役の調査と、返答に関連する、変更を先導している参加役による表示



状況管理役から状況参加役への状況変更結果の通知



状況参加役による状況データの取得

14. 意図的に空白のまま
15. 意図的に空白のまま
16. 意図的に空白のまま
17. 意図的に空白のまま
18. 登録所保存済問い合わせ: 登録所保存済問い合わせは、書類消費役が診療提供者のために、書類保管庫にむけて発行するものです。
19. 拠点認証: このトランザクションは、全てのネットワーク通信活動のなかに含まれています。全ての DICOM、HL7 と HTML 接続は、IHE の両方向認証と保護医療情報（PHI）の通信権威付与の IHE 仕様に合致せねばなりません。IHE は、PHI を伝送する他の通信プロトコルが両方向認証と通信権威付与をどの様に行うかを指定しませんが、この両方向認証と通信権威付与を行うことを必須とします。
20. 監査事例記録: 安全拠点から監査記録保管庫への監査事例記述の配達を言います。
21. 患者基本情報問い合わせ: 使用者が入力した完全なあるいは部分的な基本情報との一致に基づいて、一個の患者基本情報源にある患者基本情報を見つけて戻します。
22. 患者基本情報と来院問い合わせ: 使用者が入力した完全なあるいは部分的な基本情
報・来院情報との一致に基づいて、一個の患者基本情報源にある患者基本情報と来院情報を見つけて戻します。
23. 職員録検索: このトランザクションは DNS に問い合わせて LDAP 索引を見つけます。
24. 職員録問い合わせ: このトランザクションは職員録索引の読みだしのみの利用を提供します。
25. 「通知送信」に予約
26. 「通知受診」に予約
27. 「受信通知送信」に予約
28. 「受信通知受信」に予約
29. 「施設間使用者認証」に予約
30. 患者識別管理: 患者基本情報供給役は患者を登録ないし更新して、基本情報（すなわち、患者に直接関係する全ての情報である、ID、住所、隣人、保証人など）を、患者基本
情報消費役を実装する他のシステムに転送します。
31. 患者受診管理: 患者受診供給役は受診記録（入院、外来、仮入院など）を登録ないし更新し、患者受診情報消費役を実装する他のシステムに転送します。この情報には、患________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

216

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________者の所在と特定の医療提供者への受診記録が含まれます。
32. 書類セット媒体配布: 可搬媒体生成役は交換用媒体に書類セットを書き込みます。媒体
は物理的に他の実行役（可搬媒体取り込み役）に運ばれます。ここで書類セットを読み込み、あるいは、ZIP ファイルとして電子メールに添付のうえ送信されます。ウェブ
上での閲覧ができる様に、患者や紹介医師に媒体を提供することもできます、
33. 場所とり
34. 用紙取得: このトランザクションは用紙管理役から、要求した用紙を取得します。
35. 用紙提出: このトランザクションは用紙に書かれた個別事例データを、XML 形式で用紙受診役に提出します。
36. 用紙保存: このトランザクションは用紙に書かれた個別事例データを、XML 形式で用紙保管庫に供給します。
37. 説明取得: このトランザクションは用紙管理役から、説明書のセットを取得します。
38. 門番役間問い合わせ － 一つの共同体から他の共同体に、特定の制限を満たす臨床情報が存在する場所を同定するため、問い合わせを送ります。
39. 門番役間取得－遠隔地から医療情報の特定のセット（書類あるいは書類セット）を取得する要求を言います。
40. X-使用者特定提供－このトランザクションは、サービスの使用者からサービスの提供
者に、信頼できる使用者の特定を提供します。
41. 書類セット提供と登録-b －書類源は書類セット提供と登録-b トランザクションを開始します。提出セットのそれぞれに対して、書類源は書類保管庫へ、書類を８ビット組の無意味連続流れ（opaque octet stream）として、および、対応するメタデータとして、提供します。書類保管庫はこの書類を永続的に保存する責任と、登録所書類セッ
ト-b トランザクションを用いて、書類源から受け取ったメタデータを転送して書類登録所に登録する責任とがります。
42. 書類セット登録-b － 書類保管庫は書類セット登録-b トランザクションを開始します。
このトランザクションは、一個以上の書類を、登録すべきそれぞれのメタデータを供給して、書類保管庫が書類登録所に登録できるようにします。この文書メタデータはXDS 提出セット、XDS 書類、可能であれば XDS フォルダエントリを登録所に生成するのに使用されます。書類登録所は書類メタデータが有効なことを確かめてから登録を許します。一個以上の書類がメタデータの証明に失敗するときは、書類セット登録-bは全体として、失敗します。
43. 書類セット取得-b －書類消費役は書類セット取得トランザクションを開始します。書
類保管庫は、書類消費役が特定した書類セットを戻します。
44. 患者識別送付 HL7 V3 －HL7 V3 を使用して、患者識別供給役が患者識別に関するすべての事例（生成、更新、融合、など）を患者識別相互参照管理役に通知できるようにします。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

217

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

45. PIX V3 問い合わせ－HL7 V3 を使用して、患者識別相互参照消費役が、患者識別相互
参照管理役のサービスを使用して異なった患者識別圏内にある一人の患者識別情報を見つけることができます。
46. PIX V3 更新通知 ―患者識別相互参照消費役が、それが関心を持つ患者識別圏内の全ての患者の識別情報の変更を、患者識別相互参照管理役から通知される様にできます。
47. 患者基本情報問い合わせ HL7 V3－HL7 V3 を使用して、使用者の完全なあるいは、部
分的な基本情報との一致に基づいて、一個の患者基本情報源にある患者基本情報を、見つけ、返します。
48. 場所取り
49. 場所取り
50. 多患者保存済問い合わせ－書類消費役は多患者保存済問い合わせを書類登録所に発行して、使用者が特定した問い合わせ基準に合致する書類の所在を知ります。書類登録所は特定された基準に合致する複数患者に関連する、一個以上の書類保管庫内の対応する書類それぞれの所在と識別子を含む、書類エントリの一覧を戻します。
51. 値セット取得－値セット消費役は値セット保管庫から一個の拡張値セットを取得します。
52. 複数値セット取得－値セット消費役は値セット保管庫から複数の拡張値セットを取得します。取得したセットは、値セットを記述する完全メタデータを提供し、値セットの拡張値セットの提示を提供します。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

218

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

付録 C:

IHE 統合宣言

IHE 統合宣言は、製造者によって準備され公表された文書で、製品の IHE テクニカルフレームワ
ークとの適合性を記述したものです。任意の製品が使用可能とする特定の IHE 機能を、IHE 実行役（アクタ）と統合プロファイル （ITI TF-1: 2 に記述）の面から、特定します。
この構想になじみのある使用者は統合宣言を、メーカが製品に主張する統合のどのレベルが付随のシステムを可能にするか、どのような臨床的あるいは運用上の利益をその統合が与えるかを、決める助けにします。統合宣言は、特定の標準（例えば、HL7, IETF, DICOM, W3C, など）への適合宣言と関連させて使用する様、意図されています。
IHE は、IHE 実行役（アクタ）と統合プロファイルを試験する方法を製造者に提供します。IHE の試験方法は、コネクタソンと呼ばれる多数集団の相互試験に結実し、製造者に貴重なフィードバッ
クと実装の適合性についての基礎的指示を与えます。この方法は製品の適合性を、独立に評価、確認することを意図していません。コネクタソンの結果発表と製造者の IHE 統合宣言の入手を容易にするなかで、IHE とその支援団体は、いかなる製造者の統合宣言の正確性や有効性、あるいは、製品についての主張を、証明しません。
重要 -- 注意をお願いします: 製造者のみが、IHE 統合宣言の正確性と有効性に責任を持ちます。製造者の IHE 統合宣言は、IHE を通して利用可能になりますが、IHE は単に、特定の製品の統合能力についての情報を求める団体を考慮しているだけです。IHE とその支援団体は、IHE
統合宣言と関連する製品を評価も、承認もしておりません。IHE とその支援団体は、IHE 統合宣言の使用や依存による、業務中断、歳入の喪失を含むがこれに限定されない、いかなる団体の要求や損害について、いかなる責も負いません。

C.1 IHE 統合宣言の構造と内容製品の IHE 統合宣言は以下を含まねばなりません:
1. 販売者名
2. IHE 統合宣言が適応される製品名（宣伝で使用される名称）
3. IHE 統合宣言が適応される製品の版
4. 公表日付、オプションで、IHE 統合宣言の改訂名称
5. 以下の文言:“This product implements all transactions required in the IHE Technical________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

219

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

Framework to support the IHE Integration Profiles, Actors and Options listed
below: ”（この製品は、以下に列挙する、IHE 統合プロファイル、実行役（アクタ）、およびオプションを使用可能とすべく、IHE テクニカルフレームワークで要求される全てのトランザクションを実装している。）
6. 製品が可能とする IHE 統合プロファイルの一覧と、個々のプロファイルについて使用可能な全 ての実行役（アクタ）の一覧。
注:

製造者はテクニカルフレームワークの版を、個々の統合プロファイルに記述することができます。

個々の統合プロファイル/実行役（アクタ）の組み合わせについて、 IHE テクニカルフレームワーク
で定義された、一個以上のオプションも記述できます。
プロファイル、実行役（アクタ）とオプションには、 IHE テクニカルフレームワーク第一巻で定められた名称を使わねばなりません。
統合プロファイルの実装は、実行役（アクタ）に必要な全てのトランザクション、オプショントランザク
ションに含まれるトランザクション、必須トランザクションのオプション機能、のすべてを実装すると見なされることに、注意してください。
統合宣言は、以下の情報に対する参照やインターネットのリンクを含まねばなりません。
1. 販売社の統合宣言が置かれた、インターネットアドレス（あるいは URL）。
2. 販売社の、製品に実装された IHE トランザクションに関連する、標準（例えば、HL7,DICOM, 等）への適合宣言が置かれた URL。
3. IHE に つ い て の 一 般 的 情 報 を 記 述 し た ホ ー ム ペ ー ジ の URL（www.rsna.org/IHE）.
IHE 統合宣言は、IHE 機能を直接には実装しない製品を推奨や、広告することを意図していません。

C.2 IHE 統合宣言の書式
それぞれの統合宣言は以下の書式を使用しなければなりません。販売社は表紙や製品文書方針
に従って、他の必要な追加情報を加えることができます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

220

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

付録 D:

使用者認証技術－パスワード、生体計測、および、トークン

認証技術は３つの因子に基づきます。: 知識、人物、所有物、です。今日では多種の認証技法が使用されています。この様な技法を支える技術はよく標準化されているとは言えません。認証に使用する技術のどのような一組であれ、仕様特定を避けるのは安全上の正しい理由です。
Kerberos プロトコルはもともと、どの使用者認証技術とも動作する用に定められました。
Kerberos は広い範囲の認証技術の使用が可能なことが示されてきました。この様な技術には種々のトークンや生体測定が含まれます。この技術の特定の実装ではしばしば占有的要素が含まれます。通常、一対の占有的要素を含みます－一つは使用者のワークステーショ
ン、ヒット津は認証サーバ側の対応する要素です。いったん使用者認証が完了すると、以降の Kerberos トランザクションは同一です。
この様な拡張はいまだ標準化されていません。IHE の Kerberos 使用の仕様はこの様な拡張を特定の施設で使用することを妨げませんが、拡張が動作することを保証はしません。
施設使用者認証（EUA）に特定された Kerberos システムは、使用者の認証に、挑戦応答シ
ステムおよび、使用者名とパスワードシステムを利用しています。パスワードの最小限の支持は IHE「施設使用者認証」の標準化された基本線を提供します。Kerberos はより強力なパスワーの使用を促進する中央化されたパスワード方針の強制を可能にします。パスワ
ード方針は IHE の範囲外です。Kerberos は弱いパスワードの使用を防止しません。パスワ
ード強度の方針は施設安全管理者が選択し、強制すべきものです。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

221

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

付録 E:

プロファイル間連携の考慮

E.1 RID, EUA と PIX 統合プロファイルの組み合わせ使用
単独で使用した場合には、表示用情報取得（RID）は、患者識別圏は表示役と情報源役で同じことが前提です。さらに、情報源での使用者認証は明示的に扱われていません。この付
録では表示用情報取得（RID）と他の IHE 統合プロファイルの組み合わせを議論し、二つの問題を処理します。
同様に、情報源は、施設使用者認証を実装する実行役で認証された要求側使用者に利用制限を行うことがあります。これらの統合プロファイルを組み合わせての使用は、表示役をクライアント認証代理役と群化し、情報源を Kerberos 化サーバと群化して、実現できます。
これは図 E-1 にも示されています。

図 E-1: 多数の統合プロファイルを実装する実行役の組み合わせ使用

E. 2 と XDS と RID の統合
RID 表示用書類取得トランザクション[ITI-12]は XDS.a 書類取得トランザクション[ITI-17]に適合します。したがって、表示用書類取得トランザクションを実装する RID 情報源は
XDS.a 書類取得トランザクションを実装するのに使用できます。この事例では、RID 情報
源は安全拠点（ATNA 参照）でなければなりません。
RID は XDS.b 書類セット取得トランザクションとは適合しません。

E. 3 XDS と PIX の統合
XDS トランザクション内（XAD-Pid 圏、あるいは、HER-CR 圏のいずれか）で管理されているすべての患者 ID は、関連をもつ、患者 ID と連携する患者圏 ID（ID 割付け権限機関の OID）を含まねばなりません。この曖昧さを残さない患者識別は、書類内にある患者
ID とともに使用するよう、推奨されます。
XDS は書類内容に関与しないので、XDS 保管庫は書類のなかにある患者 ID が、この書類に関連する書類エントリにある、登録所が管理する患者 ID と合致することを確認しません。
XDS 統合プロファイルの XDS 書類源は、自身の患者 ID の総合参照を、IHE PIX 統合プロ
ファイルに影響をあたえることにより XAD-Pid 圏の患者 ID
図 E.3-1: IHE PIX 管理役による患者 ID 相互参照をもつ XDS 連携圏
図 C.6-1 に一個の患者識別圏をもつ XDS 連携圏（XAD と称す）の例と、書類源と書類消費役圏の内部にもつ患者識別相互参照管理役により相互参照を行う二つの HER-CR（それ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

222

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

ぞれ C、D2 と称す）の例を示します。
書類源は自身がもつ患者 ID と XAD-Pid 圏の ID との相互参照を、IHE PIX 統合プロファ
イルに影響力を行使して、実行する選択が可能です（図参照）。XAD 患者 ID 源からの患者
ID 送付トランザクションが、書類源が使用する患者識別相互参照管理役への入力として使用可能です。PIX 管理役は EHR-CR の内部にあるか、XDS 連携圏内で共有するかします。

E. 4 XDS と PWP の統合
XDS 統合プロファイルの XDS 書類源は、PWP 職員録問い合わせ[ITI-24]トランザクショ
ンを利用して、書類セット登録-b[ITI-42]と書類セット提供と登録-b[ITI-41]トランザクショ
ンで、authorPerson と legalAuthenticationName データ野に入れるのに必要な情報を得る
ことを選択できます。
職員録トランザクションでは、
ITI TF2a: 3.24.4.1.2.3.1 節で、個人情報について HL7 XCN（個人の拡張復号 ID 番号と名前）形式の情報を含む”large-x-ihe”の”cn”属性を定めています。このデータ野は PWP 統合プロファイルではオプションです。療養提供施設は、職員録索引でこのデータ野に値を入れ、ITI-24 トランザクションを利用して XDS 活動をささえる
ことを選択できます。これは必須の依存関係では内ですが、書類源と職員録消費役とを群化する理由の一つです。
PWP 統合プロファイルは職員個人情報のみを提供します。組織についての情報は他の手段でたとえば、LDAP 索引を組織対象に拡張して、取得せねばなりません。

E. 5 XDS と PDQ の統合
基本情報問い合わせ（PDQ）統合プロファイルは XDS 統合プロフィイルとともに使用して、XDS 連携圏患者識別子を XDS 書類消費役と書類源に探すための参照を提供します。この場
合、現場の患者特徴に基づいて XAD 識別圏内で候補となる患者 ID の選び出し用一覧を問い合わせることは望むなら、患者基本情報供給役は XDS 患者識別源と群化される必要があ
り、他方、患者基本情報消費役は書類源・消費役と群化される必要があります。

E. 6 XDM と XDS, 内容統合プロファイル、PIX、DSG との統合
XDM 統合プロファイルは書類の内容や目的を制限しません。内容統合プロファアイルはこの様な制限を加えます。
XDM プロファイルは患者整合の問題を処理しません。PIX、PDQ 機能は可搬媒体取り込み役で使用可能ですが、XDM プロファイルはこれを要しません。可搬媒体取り込み役で PIX,PDQ が使用できない場合、患者識別情報に必要な強制的変更を行うその他の方法が提供されねばなりません。用手的修正は、小さな規模の施設に意図した可搬媒体取り込み役では可能です。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

223

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

施設間書類媒体交換（XDM）統合プロファイルが DSG 統合プロファイルと共にしようして書類内容と XDS メタデータのデジタル署名の機能を提供します。

E.7 XDM/XDR の区別
XDR も XDM も患者書類のセットの交換を扱います。参加施設の一つで XDS が実装されていない、あるいは、使用できない場合、あるいは、一対一通信が（登録所を介する共有よりも）望まれる場合では重要です。
XDM は情報の受け手がデータと関連書類を用手的に解釈あるいは調べる状況で適用されます。XDM では複数患者に関連する書類を含む一回の交換を可能とし、持続性のネットワーク機能が参加医療施設の一方あるいは両方にない状況で使用可能です。
XDR は、一人の患者について書類を自動的に保存ないし処理する自動機能がある自動化シ
ステムあるいは汎用システムに、交換される情報が送られる状況で、使用可能です。XDR
ではデータ交換する医療提供機関の間で、持続的なネットワーク機能が必須です。

E. 8 XDR と XDS、内容統合プロファイル、PIX、DSG との統合
E.8.1 XDR と XDS との統合
XDR と XDS は似通っており、相補的です。
両方のプロファイルは内容を関知せず、メタデータの同じセットを変更したり管理せずに伝送します。両者とも、書類源が一セットの書類を他の IHE 実行役に、HTTP に基づくオンラインで、あるいは、SMTP に基づくオフラインで、伝送します。
しかし両者は重要な点で異なっています。XDS は”サーバ”（登録所とおそらく保管庫）と”クライアント”（源と消費役）をもつ中心化されたプロファイルです。XDR はより対称的（源と受け手）です。
書類源と書類受領役が同じ連携圏に属すなら、この連携圏で定められた規則（患者 ID、割り付け権限機関、コード化方式、、、）を遵守せねばなりません。
実行役のすべてが同じ連携圏に属するのでないなら、以下のオプションがあります。


書類源が書類セットを書類保管庫に送ると「同時に」（結果のネットワークオンライン
通信文）、書類受領役にも送るなら、書類源と書類保管庫を含む連携圏がさだめた規則が使われねばなりません。



その他の場合:

書類源と書類受領役が使用する規則を合意する（たとえば、PIX 適合サーバから利用できる「地域患者 Id）を使用する）。この規則が使用されねばなりません。

注: このような「相互合意」定めることが強く推奨されます。



さもなければ、書類源側で使用できる規則を使用し、書類受領役は患者 ID とコードを現地の規則に従う様に変換せねばなりません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

224

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

施設間高親愛交換（XDR）統合プロファイルは XDS 統合プロファイルと一緒に使用して、施設間共有と一個以上特定の相手への一セットの書類送信の両方の機能を提供します。書
類源が XDS と XDR の両方の統合プロファイルを使用可能とするときは、以下の図に示された様です。
図 E.6-1: XDS, XDR, XDM プロファイルの連携

E.8.2 XDR と XDS 内容統合プロファイルとの統合
施設間書類高信頼交換（XDR）統合プロファイルは任意の数の XDS 内容統合プロファイル
と共に使用できる様に意図されており、交換された書類の内容の相互運用性のある仕様を提供します。どの XDS 内容統合プロファイルも、たとえば、スキャン画像用の XDR-SD（IT
基盤テクニカルフレームワーク参照）、医療要約用の XDS-SM（患者療養得協働テクニカル
フレームワーク参照）、は XDR とともに統合可能な内容統合プロファイルの例です。これらの内容統合プロファイルは XDS-SD と言われますが、名称にある XDS はその使用が XDSに限られると暗示するものでないことに注意してください。XDR は、同様に、一対一の交換を意図したものです。
E. 8.3 XDR と PIX の統合
施設間書類高信頼交換（XDR）は PIX 統合プロファイルと共に使用可能で、書類源が使用する患者識別子と書類消費役の患者識別子との相互参照、あるいは結びつけを提供します。
この統合的使用では、XDR 書類源、XDR 書類受領役と PIX 患者識別源とを群化する必要があります。この結果、PIX 管理役に、書類源と書類受領役識別圏の患者識別が送付されます。さらに、書類受領役は PIX 患者識別消費役と群化されねばなりません。その結果、
XDR 書類セット提供と登録トランザクションの XDS 書類メタデータのなかで、患者識別子が受領したとき、PIX 管理役のサービスが惹起され、受け取った患者識別子と書類受領
役識別圏の患者識別子とを相互参照します。

E.9 XCA と XDS および非 XDS 共同体との統合
この節は情報提供で、共同体が使用しうる設定のいくつかを提案します。以下の共同体が記されます。


XDS 連携圏



非 XDS 連携圏



XDS 連携圏の集合



非 XDS 連携圏の集合

透明な門番役を持つ XDS 連携圏

E.9.1 XDS 連携圏________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

225

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

以下の例では、応答側共同体は XDS 連携圏で、応答側門番役がサービスしています。
図 E.9.1-1: XDS 連携圏
E. 9.2 非 XDS 連携圏
以下の例では、応答側共同体は応答側門番役にサービスされています。しかし、この共同体内では XDS 登録所や XDS 保管庫を持っていません。応答側門番役は、門番役間問い合
わせと門番役間取得トランザクションに応じてデータを集めるため、独自の機構が使用されます。
図 E.9.2-1: 非 XDS 連携圏
E.9.3 XDS 連携圏の集合（情報提供）
以下の例では、一個の応答側門番役が二つの共同体にサービスしています。それぞれの共同体は XDS 連携圏でそれ自身の応答側門番役を持っています。: 発動側共同体からはこの二つの応答側門番役は隠されています。
この例は単に情報提供のためです。このプロファイルは、この特定の設定を使用可能としませんし、この様な設定の全てを処理する訳ではありません。

図 E.9.3-1: XDS 連携圏の集合
E.9.4 非 XDS 連携圏の集合
以下の例では、一つの応答側門番役が二つの共同体をサービスしています。それぞれの共同体は非 XDS 連携圏でそれ自身の応答側門番役を持ちます。: この二つの応答側門番役は発動側共同体からは隠されています。
この例は単に情報提供用のものです。このプロファイルは、この特定の設定を使用可能としませんし、この様な設定の全てを処理する訳ではありません。

図 E.9.4-1: 非 XDS 連携圏の集合
E.9.5 2 透明な XCA 門番役をもつ XDS 連携圏（情報提供）
以下の例では、発動側共同体は XDS 連携圏で、発動側門番役は XDS 連携圏登録所と群化されています。書類消費役は、現場および現場以外のデータを取得するため、一個のシス
テムと相互作用します。これは「透明門番役」と言われますが、これは使用者が明示的に共同体間通信を目にせず、登録所と代理保管庫により隠されているからです。メタデータに現場以外の保管庫識別子が見つかるときは、設定では書類消費役が発動側門番役と通信する様にする必要があります。この様にして、書類消費役が、発動側門番役を代理保管庫として相互作用します。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

226

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

この図は応答側門番役が書類登録所と群化されているのが示されています。
この例は単に情報提供です。このプロファイルは、この特定の設定を使用可能としません
し、この様な設定の全てを処理する訳ではありません。

図 E.9.5-1: 透明 XCA 門番役を持つ XDS 連携圏

E. 10 XCA と患者識別管理
この節では、共同体間データ交換環境で患者識別を解決する二つのモデルを記述します。
XCA 統合プロファイルは患者識別管理を意図したものでないので、XCA と他の適切な患者識別管理の統合プロファイルと組み合わせる必要があります。この節は情報提供で、この領域に存在する二つの既存 IHE 統合プロファイル、患者識別相互参照（PIX）と患者気品
情報問い合わせ（PDQ）、に依存した二つの可能な解決法を記述します。この記述は高所からの概観で、このモデルを実装するには詳細（ここでは記述されません）が必要です。患者識別の他の識別法が存在しますが、ここでは記述されません。IHE ITI 基盤技術委員会は
将来もっと洗練された方法を作り出すでしょう。

E.10.1 PIX を使用した患者識別以下の図は、最上位に PIX があり、共同体 A, B, C の間の相互参照を行う場合の、患者識別管理の機構を記述します。この図ではそれぞれの共同体の応答側あるいは発動側門番役は最上位 PIX に患者識別送付を行うため、相互作用することを前提にしています。この図には遠隔共同体 B, C で問い合わせに応答する処理は含まれていません。最上位 PIX はこの
例では定義されていませんが、PIX 管理役やその相当で、すべての共同体を利用できます。

図 E.10.1-1: PIX を使用した患者識別E.10.2 PDQ を使用した患者識別以下の図は現場と遠隔の識別子の間で相互参照できる役がいない場合の共同体間交換での患者識別を記述します。遠隔共同体（B と C）の役の間での相互作用はこの図では詳細に書かれていないことに注意してください。
図 E.10.2-1: PDQ を使用した患者識別
この図では、発動側と応答側門番役による、既存の IHE 患者基本情報問い合わせ（PDQ）
統合プロファイルに依拠する基本的方法を示します。ここでは、応答側門番役が自身の共同体内の患者に対する患者情報特性での問い合わせに応答し、発動側門番役が患者 ID を取得して共同体間問い合わせに使用できる様にします。このトランザクションの結果は、a)
ゼロで、患者がその共同体には記録を持たないこと b) 一個で、患者を一意に識別可能なこ________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

227

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________と c) 複数で、応答側門番役は患者を一人に特定できなかったこと、です。a)や b)の場合はトランザクションは完結し、ヒトの介在は必要ありません。複数結果が返されたときは、解決のためにヒトの介在が必要です。
この方法では、かなりの数の方針決定が、図 E.10.2-1 に示された PDQ と XCA の組み合わせ使用の範囲を超えた共同体間環境でのプライバシ同意と、協調して動いていることが必要です。さらに、応答側門番役が患者識別を解決する要求を処理できる様にするには、重複しない多数の患者をもつ多数の共同体の統合にかなりの規模問題を処理する必要がありそうです。
IHE のこの領域での作業は、将来もっと洗練された、XCA と結合できる統合プロファイルを作り出すでしょう。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

228

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

付録 F:

標準作成組織への要望

この付録は空白です

付録 G:

安全の考慮

G.1 施設間プロファイルの考慮
IHE に適合するシステムは通常医療情報を処理します。これは、国のプライバシ規制、その他の州あるいは契約上の要請に従います。IHE 基盤プロファイルこの情報を保護する十分な安全機構を完全には定義していません。施設使用者認証はこの解決の一つの解決法です。
IHE は以下の特性をもつ拠点に実行役が設置されていると想定しています。


それぞれの拠点は安全方針をもつその運用の手順を定めています。これは医療施設の安全方針の一部と想定されます。



拠点境界の外部にいる全ての使用者（ヒト、アプリケーションの手順、など）は利用制限処理を受け、使用者・アプリケーションは認証されます。



全ての必須の監査事例は取得され記録されます。

このテクニカルフレームワークのプロファイルは以下の環境を想定しています。
物理的に安全な環境
機器は物理的に防御された場所にあり、看視されています。患者安全、プライバ
シ、および運用上の関心から、これは通常撮影機器では当てはまっています。同様に HISシステムや種々の保管機器は通常防御されています。PACS ワークステーションの様な機器はときに非防御領域に置かれますが通常病院職員が監視し、出入り制限を行う場所にあります。機器の変更の脅威は物理的安全機構で防御されていると想定されています。
コンピュータをつなぐネットワーク機器は、不正な接続や不正な変更からぶっつり的に防御されていると想定されています。多くの病院の治療場所ではネットワーク機器
は天井裏、結線路、鍵付きキャビネット、その他の防御された場所にあります。通常職員がいて、許可のない活動が無いように看視しています。
病院の上記以外の場所、たとえば管理職事務室、でも、物理的安全想定が有効であるよう保証する、現場での手順と運用が行われています。管理食事務室はリスクが高いです。


遠隔地、特に家庭事務室は物理的んい保護されていません。装置の防御を行う、同等の防御を提供する他の手段が使用されます。これには、VPN 接続、
HTTPS 接続暗号化の使用があります。暗号の使用や VPN は物理的安全の完全な代替にはなりないことがあります。



個人的、と仕事上の二つの目的で使用する家庭コンピュータは防御困難です。
悪意あるソフトウェアによる予期せぬ変更から防御され、悪意あるソフトウ
ェアの使用は禁止されねばなりません。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

229

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________



ネットワーク安全環境ネットワークの物理的安全に加え、監督されていないシステムによるネット
ワーク利用からの防御があります。これには、典型的には、ファイアウオー
ルや VPN があります。

脅威のプロファイルは以下です。


事故あるいは不注意による誤用



個人的利益、悪意、復習、好奇心による乱用。乱用者は基礎のシステムとア
プリケーションには限定的な利用しかしません。彼らはシステムの内部についての専門家ではありません。



無作為の特定の標的無しの乱用、たとえばインターネットハッカーからの乱用です。

脅威のプロファイルには以下の脅威が無いか、さもなければ、防御されています。
システム管理者、システム開発者、その他の専門家により個人的な乱用

軍あるいは敵対政府による活動



組織化された犯罪攻撃

IHE は IHE 医療アプリケーションの範囲内で IT システムに関連した安全要求のみを扱います。ネットワーク攻撃やウィルス感染などから防御するための安全要求事項を扱いません。
IHE は現在の暗号化の動作への影響が大きすぎるため、暗号化の使用を必須としません。
多くの病院は物理的および手順によって十分な安全を提供しています。暗号化によるコンピュータ動作性能の追加の低下はこの様なネットワークでは正当化されません。プロファ
アイルは暗号化の使用を許しますので、全般的安全計画に組み込めます。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

230

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

付録 H: 意図的に空白のままです。
付録 I: 意図的に空白のままです。
付録 J: XDS 文書の内容と形式
XDS 統合プロファイルでは多くの方針を XDS 連携圏が定める様に任せています。たとえば、共有する XDS 書類内容の構造と形式、内容メタデータの XDS 書類登録所への対応付け、XDS 書類メタデータのコード化、XDS 提出要求のきっかけ事象、共有を促進するためのフォルダ使用に関する方針などです。
施設間書類共有での十分な経験が得られるまでは、XDS 統合プロファイル使用の共通ある
いは最良の実践法を確立することは不可能であると認識するのは重要です。IHE はこのため、この点については推奨を行うことを控えました。
IHE はこの統合プロファイルと共同する内容指向の統合プロファイルの必要性を認識しています。将来、種々の IHE 領域（患者療養協働、心臓、検査、放射線、IT 基盤、など）で連携圏内での XDS 使用を洗練する IHE 統合プロファイルを作成すると期待されます。内容指向の統合プロファイルは XDS に依拠する可能性がありますが、共有する書類の形式に
さらに制約を置くか、フォルダや提出セットなどの XDS 特性の使用を制限するでしょう。
内容中立性
XDS は内容に関知しません。様式、内容、構造、XDS 書類保管庫から取得できる書類の表示、を規定も禁止もしません。XDS 統合プロファイルが XDS 連携圏に即時の価値を待つには、連携圏のメンバーで使用可能で現存する書類に適合できねばなりません。このため、内容の制限は XDS 統合プロファイルの有用性と適用を制限するのみとなります。同様に、
XDS 連携圏はこれからできる標準にも適合できねばならないので、規定された内容形式の一欄に列挙できません。
IHE は、
XDS 連携圏は、
可能な限り、
広く受け入れられた標準（HL7 CDA, CEN ENV 13606,
ASTM CCR, DICOM 複合物）に書類が適合するよう要求する規則を適用することを強く推奨します。
書類ヘッダとメタデータ
XDS は内容を関知しないので、XDS 書類内のメタデータを XDS 書類登録所に供給されたメタデータと照合することはできません。XDS 連携圏は IHE が統合プロファイルを定めた
領域の内容を選択するか、XDS 連携圏は、その時点まで、XDS 書類登録所で如何に属性が埋められかを注意深く定めるか、せねばなりません。
メタデータと患者記録
書類ヘッダ内のメタデータは XDS 書類登録所で重複生成されますが、XDS 書類登録所メタ
データは保存された法的医療記録の一部である点で特別な役割を持ちます。これは書類が置かれた XDS 書類保管庫が管理するので、臨床記録の一部では確かにありません。
さらに、
XDS は XDS 提出セットの内容に署名する、あるいは、認証するトランザクション（IHE________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

231

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

書類デジタル署名内容プロファイル-DSG 参照）を持ちませんが、XDS 連携圏が施行する様に望むなら、著者を追跡する機能を提供します。寄せられた提出書類セットへの書類参照をフォルダ内に置くことにより、XDS フィルダの内容は追跡されます。しかし、登録所に書類メタデータが存在すること、および、XDS 提出セットやフォルダの作成時に含まれる可能性のある医療法律のために、XDS 書類登録所の内容が患者の法的医療記録の一部になります。この様な臨床法令に含まれる問題を常識、受容できる医療実践、地域の規制に当てはまる様に、如何に処理するかをきめるのは、それぞれの XDS 連携圏に任されています。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

232

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________付録 K:

XDS 構想の詳細

K.1 XDS 文書の構想
XDS 書類は、書類保管庫に提供でき、書類登録所に一つのエントリーとして登録する、最小単位の情報です。
XDS 書類は、観察結果とサービスからなる複合的な臨床情報で、以下の特性を持ちます: 永続性、世話役特性（stewardship）、認証をうける可能性、全体性。これらの特性は HL7 のCDA 第１版仕様（Clinical Document Architecture Release 1 specification）に定義されています。
XDS 書類はヒトおよび・またはアプリケーションで見読できるものです。いずれの場合も、構造、内容、コード化を定める公表された標準に合致せねばなりません。IHE は XDS とともに仕様で切り、この様な内容についての標準に依拠した内容指向統合プロファイルを泥議するつもりです。
さらに:1.

共有のために提出するとき XDS 書類は、書類保管庫へ MIME タイプとともにオクテットストリームとして提供されねばなりません2.

書類取得トランザクションで取得するとき、XDS 書類は提出されたオクテットストリ
ームのまま、無変更でなければなりません（高忠実度保管庫）。
注: XDS 書類は MIME 多パート書類（たとえば HL7 CDA が最初のパートとして、次の添付分がファイルとして送られる）のことがあります。最初のパートは書類の一次パートを含み、他のパートは最初のパートに対する直接の添付です。書類保管庫はこの多パートデータを”無意味エンティティー（opaque entity）”として扱います。書類保管庫は多パート構造を解析、処理する必要はなく、また、どのパートの内容も XDS 統合プロファイルの状況で解析、処理する必要もありません。
注: XDS 書類は、書類に特異的な代替の取得方法によっても取得できます。このようなオプシ
ョン機能は現在の XDS 統合プロファイルにはありませんが、将来のオプションとしての追加の
候補です。

3.

XDS 書類は書類源が定めたメタデータと関連させねばなりません。このメタデータ情報は XDS 登録所によって XDS 書類エントリにおかれねばならず、XDS 消費役により問合せのために使用されます。

4.

XDS 統合プロファイルでは XDS 書類を一単位の情報として管理し、XDS 書類の一部を利用する機構を提供しません。書類源と書類消費役のみが XDS 書類の内部情報を利用できます。

5.

XDS 書類は世界規模で一意に識別されますので、異なった内容を持つ二つの XDS 書類
が同じ固有識別子（Unique Identifier）を持つことはありません。この識別子は XDS
連携圏のすべてを通じて一意で、異なった連携圏からの XDS 書類保管庫の融合、もし望めば、XDS 書類の臨床連携圏間での交換を可能とします。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

233

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

6.

XDS 書類登録所は書類保管庫に保存されたそれぞれの XDS 書類の一個のエントリを維持せねばなりません。同じ XDS 書類の重複コピー（同じ固有識別子（Unique
Identifier））を保存し登録することができます。同じ固有識別子を持つが異なった内容を持つ書類は拒否されます。

7.

この統合プロファイルでは書類登録所に登録された XDS 書類のそれぞれに必要なメタデータを定めています。XDS 書類のメタデータが関連する XDS 書類の実際の内容を反映するのは書類源の責任です。書類保管庫も書類登録所もこの一貫性を調べません。

8.

書類源は登録した XDS 書類の以下の責任を維持します。
a. この様な書類のどれであっても、状態を”承認済み”から”廃止済み”あるいは削除する権利を持ちます。
b. 従前に提出された書類の一つと、置換えの「親関係」（RPLC）を持つ XDS 書類を提出する権利を持ちます9。

XDS 連携圏は必要に応じて、患者にこのような運用を提供するため、XDS 連携圏は方針と手順を持たねばなりません。たとえば、ある地域では、患者が書類の EHR-LR からの削除を要求することがあります。登録所と保管庫の実装社はこのような局所の運用を可能とせ
ねばなりませんが、今のところこれを行うトランザクションは定められていません。

K.2 XDS 連携圏構想
XDS 連携圏は、臨床書類を共有することに同意した、良く定義された書類保管庫と書類登録所のセットからなります。XDS 連携圏には以下の属性が定義されています。:
1.

XDS 連携圏は療養を提供しません。XDS 連携圏に、書類源と書類消費役として属する
EHR-CR のみがこれを行います。

2.

XDS 連携圏は一個の書類登録所で管理されます。
注: 分散型登録所は将来、別の統合プロファイルとして考慮されます。書類源と書類消費役では、一個の書類登録所は分散配置された登録所による複雑性を隠せます。

3.

書類保管庫はいくつあっても良いです（分散型設定が既定ですが、中央化された一括化した登録所と保管庫も可能です）。

4.

書類共有に参加する書類消費役と書類保管庫はの明示的一覧表を含みます。書類保管庫や書類消費薬の追加は管理薬の業務で、登録所と保管庫を維持する責任期間の参加を要します。

5.

EHR-CR と XDS 連携圏のそれぞれには使用者（医療職）間の信頼の鎖があります。

6.

書類保管庫と書類消費薬は１個を越える XDS 連携権威属すことがあり、同じ、あるいは異なった書類を共有します。これは実装の戦略であり、これ以上議論されません。

9

たとえば、DICOM では、書類の識別は内部の患者メタデータが更新されても、更新されませんので、書類源は既存書類の置き換えとして、更新された DICOM 書類を提出します________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

234

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

7.

XDS 連携圏は、書類登録所と通信する書類源と書類消費薬が使用する、一次患者識別圏の使用を可能とします。XDS 連携圏内の書類源と書類消費薬が、異なる患者識別登録圏に属するとき、種類源と書類消費役は、自身の患者識別登録圏と登録所とを相互参照せねばなりません。IHE 患者識別相互参照（PIX）統合プロファイル、IHE 患者
基本情報問合せ（PDQ）あるいはその他の XDS 連携圏に特異的な相互参照の機構、を使用できます。

8.

書類源は、XDS 連携圏が認める語彙値セット（Vocabulary Value Set）から引用した
書類コードと医療施設コードを持つ書類のみを寄稿できます。

K.3 XDS の他の原理
XDS 統合プロファイルは以下の制約と原理のもとでデザインされました。
1.

書類は、XDS 書類登録所の管理下にない他の書類への参照を、その内容に含むことがあります。このような参照は、その参照を含む書類を登録した EHR-CR に使用可能であることがあります。EHR-CR の内部にあるこのような書類の利用は XDS の範囲外です。

2.

XDS 保管庫は書類内容の処理、変更を書類内容に加える様には期待されていません。
処理と変換は源の EHR-CT か消費側の EHR-CR の責任です。書類内容の分析、書類
間区見回せ、提示は XDS 統合プロファイルと実行役の範囲外です。

3.

登録された書類に含まれる臨床情報の守護は EHR-CR の源役にあります。
EHR-LR は、書類を寄せる EHR-CR のそれぞれの責任のもとで、共有空間を提供するのみです。

4.

XDS 書類が XDS 連携圏の XDS 登録所に既登録の場合、XDS 書類は同じ書類固有識別子をもつ、あたかも新しい XDS 書類の様に再提出されます。この二重提出は書類労特所・保管庫において、同じ書類固有識別子を持つ XDS 書類が書類エントリにあること
により、検出されます。再提出された書類が属する提出要求は、固有識別子が合致するにもかかわらず実際の内容が異なる場合（提出時に書類保管庫が計算するハッシュ値を使用して検出されます）には拒否されます。

K.4 書類の同定
XDS 書類に関連する固有識別子の数を減らすため、書類源が割り付ける世界規模で一意の書類 Id（globally unique DocumentId）と保管庫が使用する固有 XDS 書類 Id（unique XDS
Document Id）は同じです。IHE トランザクション操作のコード化を内部的に参照する書
類エントリを参照するため、ebRS に従って作成された書類エントリ UUID の使用を制限することを強く推奨します。すべての外部操作（たとえば、書類源の内部にあるデータベースで維持されるリンク、書類内でのリンク）に対して、世界規模で一意の書類 Id（globallyunique DocumentId）を使用することを推奨します。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

235

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________XDS 書 類 エ ン ト リ は 二 つ の 異 な っ た 属 性 を 持 ち ま す : XDS 書 類 固 有 Id
XDSDocument.uniqueId

（

）

と

XDS

書

類

保

管

庫

固

有

Id

（XDSDocument.repositoryUniqueId）です。書類固有 ID は場所に無関係な識別子です。
その結果、XDS 書類が XDS 連携圏内の一個の XDS 書類保管庫から別の保管庫に移動すると.repositoryUniqueId は変化しますが、Document.uniqueId は変化しません。

K.5 書類の関係例

図 K.5-1: 書類関係の例
このような関係を上の図に示します。典型的な想定手順は単純置き換え（たとえば、
XDSDcumentId"1.2.345.678910.266"が XDSDocumentId "1.2.345.678910.123"を置き換える）、単純追加（たとえば、XDSDcumentId"1.2.345.678910.456"を XDSDocumentId"1.2.345.678910.123"に付加する）です。より複雑な、予期される想定業務手順は以下です:

追 補 の 置 き 換 え （ た と え ば 、 XDSDcumentId"1.2.345.678910.224" がXDSDocumentId "1.2.345.678910.456"を置き換える。これは、XDSDocumentId"1.2.345.678910.123"の追加です。）－予期される振る舞いは、置き換えを追加に
す る こ と で す （ た と え ば 、 XDSDcumentId"1.2.345.678910.224" を
XDSDocumentId "1.2.345.678910.123"の追加にします）；



置き換えられた書類への追加（たとえば、XDSDcumentId"1.2.345.678910.456"
が XDSDocumentId "1.2.345.678910.123" に 追 加 さ れ ま す 。 こ れ は 、
XDSDcumentId"1.2.345.678910.266"で置き換えられています。）－予期される振る舞いは、追加を置き換えとともに行うことです（たとえば、
XDSDcumentId"1.2.345.678910.456"を XDSDocumentId "1.2.345.678910.266"の追加にします）。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

236

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________付録 L:

XDS 連携圏定義のチェック表

XDS 連携圏の構想は ITI TF-1: 10 と ITI TF-1: 付録 K に定められています。ITI TF-1: 付
録 L は情報提供のための、XDS 連携圏に EHR-LR 書類共有環境を配備するために処理されねばならない重要方針のチェック表をもともと提供しました。しかし、このチェック表
は、多くの必要な XDS 連携圏配備の問題を扱っていなかったため、不完全だと認識されました。このような欠点を補うため、新しい、XDS 連携圏配備計画雛形（Template for XDS
Affinity Domain Deployment Plannnig）白書が作成されました:
http: //www.ihe.net/Techinical_Framwork/index.cfm#IT
これは、考慮すべきすべての問題のアウトラインとして働き、特定の実装の正しさをチエックする一覧表でないため、雛形の形式をとります。この新しい雛形は、一個の XDS 連携
圏の、あるいは、ある国あるいは地域での復数の XDS 連携圏の方針を定めるのに使用できます。
こ こ で は 新 し い 「 XDS 連 携 圏 配 備 計 画 雛 形 （ Template for XDS Affinity Domain
Deployment Plannnig）」に定められた話題の要約を示します。


組織規則


サービス水準の合意、日常統括、設定管理、データ保持、保存、バックアップ、災害からの復旧



会員規則




外部システムからの XDS 連携圏への接続性

患者プライバシと承諾

着手と使用、患者承諾、強制のガイドライン




用語と内容

メタデータの洗練化と内容属性の使用


システム構造

全般的構造、連携圏実行役、トランザクションの支持

承認、会員の種類、会員資格方針

技術的安全

権威付け、役割管理、使用者・役割認証、拠点認証、証明書管理、情報利用安全、情報
統合性、更新と維持の方針、安全監査追跡、時刻一貫性、監査チエック、リスク分________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

237

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

付録 M:

施設間書類共有と IHE 道程

IHE 施設間書類共有は IHE 統合プロファイル集団の一部で、領域特異的テクニカルフレー
ムワーク（たとえば、患者療養得協働、心臓病、検査、放射線、IT 基盤など）にまとめられたものです。
XDS は施設医仇相互運用性の基盤で、多数の既存 IHE 統合プロファイル（ITI
TF-1: 付録 E を参照）と一緒に使用可能です。しかしながら、関連する基礎標準の利用を中止して、多くの新しい統合プロファイルが開発されねばなりません。

M.1 XDS の書類内容統合プロファイル
種々の IHE 領域（心臓病、検査、放射線、IT 基盤など）が共有の必要がある書類の内容を扱う新しい IHE 統合プロファイルを作成すると期待されています。この様な「内容指向」
統合プロファイルは XDS 統合プロファイルに依存して、共通の方式で登録、発見、利用の過程を管理すると思われます。
この様な努力は、IHE 患者療養協働領域の、紹介用の診療要約と退院要約や他の書類で進行中です。www.ihe.net を参照してください。

M.2 施設間動的情報共有
動的情報、たとえばアレルギーの一覧、使用役一覧、問題一覧など、の管理は XDS では扱
われません。しかし、この情報を構造化された形式で利用する手段やこの様な動的臨床の更新を管理する手段は、特定の統合プロファイルの候補です。

M.3 共同業務流れ処理管理
XDS が部分的な解決（患者記録の生成と結果として生じる永続的人工物）しか与えられないオーダの発行と追跡（たとえば、薬品の処方、放射線オーダ、など）の様な協働過程の共有療養提供には幅広い変動があります。XDS は、電子処方、電子紹介、に不可欠の基盤を提供し、その中で、種々の療養提供者が、オーダ、処方、分配、および結果の共有を保証できる様にします。この協働作業流れの処理の命令・制御部分に相互動作する手段は、
将来の統合プロファイルの候補です。

M.4 安全とプライバシー管理
XDS 連携圏の運営には、適切な安全モデルが動作していることが必須です。安全モデルの範囲は可能なものである様に期待されています。XDS 統合プロファイルは特定の安全モデ
ルを含む様に意図されても、必要でもありませんが、XDS 実装品は XDS 実行役と IHE 査
察監査追跡と拠点認証の実行役と群化する必要があり、この様な施設間環境で動作する利用制御が必要です。XDS に追加する特定の IHE 統合プロファイル（たとえば、施設間使用者認証、書類デジタル署名など）が使用可能です。

M.5 XDS 連携圏の連合
XDS は、療養提供組織を地区、地域、国のどのレベルも含む XDS 連携圏を設立する効果的な手段です。しかし、患者が地域から地域へ、国から国へ、移動するとき、自分の記録がこれに追随することを望むため、独立した一貫性のある XDS 連携圏の設立は、一つの XDS________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

238

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

連携圏の連合の必要を生じます。IHE は、一つの XDS 連携圏から他の連携圏への転送の必要、一つの XDS 連携圏から他の XDS 連携圏で管理される書類の利用の必要を予見しています。XDS はこの様な拡張を念頭においてデザインされました。XDS を補強する共同体間
利用（XCA）がこの機能を提供します。

付録 N: 意図的に空白のままです。
付録 O: 意図的に空白のままです。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

239

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

付録 P:

プライバシ利用方針（情報的内容）

この付録は、同意が自動的に行われけっｋとして BPPC が使用可能な場合についての情報を提供します。プライバシ許諾は、”私は自分の個人情報が特定の条件のもと、他人に公開されることに同意します”と要約できます。
条件は種々の因子により、たとえば以下の様です。


公開する相手のタイプ



公開するデータのタイプ



利用のタイプ（通常利用、救急時利用、、、）



公開する場の安全レベル（弱い認証か強い認証か）

データを公開する目的のタイプ

期間（承諾の有効期間、公開期間、、、）BPPC は、因子が限定され、定義され、基本患者プライバシ承諾強制オプションを実装する書類消費役が容易に解釈できるような環境では使用可能です。
XDS 連携圏プライバシ承諾方針によい種々の動作が起こります。たとえば、


書類消費役の使用者に、特定の書類の存在の表示を制限します

書類消費役の使用者に、特定の書類の利用を制限します

警告文の表示（現在の利用について、あるいは、追加の公開は許可されていない、追加の承諾が必要、、、）

新しい承諾の収集（口頭同意、患者認証、電子署名の承諾、紙の承諾、、、）________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

240

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

P.1 機微と記された場合の承諾と役割に基づく利用制限
一つの可能な解決法は方針と機微性印の集合からなる利用制御行列の作成です。以下の表に、単純な利用制御行列の例を示します。

この行列の各欄は一個の患者プライバシ方針です。この語彙は XDS 連携圏で設定されねばなりません。それぞれの患者プライバシ方針について XDS 連携圏内のアプリケーションが認識できる様にする設定が特定され、どのレベルの機微性（confidentialityCode）、どのタ
イプの利用が許されるかを特定します。上記の例をしようして、患者プライバシ方針は以下の様になります。
表 P-2: 書類秘匿コード（機微性）で示された患者プライバシ方針________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

241

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

患者プライバシ方針が決まっている限り、他の利用制御行列の分割も可能です。
ここに提示した用語と構想の理解に資する良い参考として以下に参考文献を挙げます。


ISO/TS 21298 "Health Informatics - Functional and structural roles"



ISO/TS 22600 "Health Informatics - Privilege Management and AccessControls"



CENprEN 136604-4 "Health Informatics - Electoonic health record communication Part 4: Security requrements and distribution rules"

P.3 実装に考えられるチエック表
一般（まず最初に）


秘匿性実装の粒度


書類の粒度：すべての書類、書類のタイプ、それぞれの書類



使用の粒度：全使用者、使用者のタイプ、それぞれのタイプ

秘匿性実勢の深度

患者の使用可能書類の一覧が使用者に読めない書類が存在（メタデータ）するか？



使用者は自分が見られない書類がある・あり得ることを知っているか？



使用者や書類のタイプにより、秘匿度の深度を管理する可能性があるか？



利用者、書類、方針を如何に同定するか？



秘匿性管理は、さらなる使用にも（いったん使用者が取得したら）波及するか？

実装の間


場所やハードウエア、著者、患者、、、による既定のコードの定義



実装のオプション

選択用の一覧表の可能性と一覧を如何に作るか（あらゆる可能な値から、あるいは、患者が通知された値から、、、）


出版前の既定値変更の可能性秘匿コ－ドにもとづいて書式が異なる可能性（ダウンロードできない画像のみ、pdf, word,,,）

方針の後日変更（書類要求時に直接、事前証明か）________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

242

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

出版の前に




出版のまえにチエックする要素はなにか：


方針の存在



使用した方針の存在



方針の承諾

与えられるべき追加の情報は（一般承諾方針、患者特有の承諾方針、、、）？

書類利用を許可する前に

出版のまえにチエックする要素はなにか：

利用する使用者の役割

使用された方針と利用する使用者の関係

特定の利用と秘匿方針救急（特定の方針、秘匿方針の近道、、、）



break glass(用事特権取得)与えられるべき追加の情報は（一般承諾方針、患者特有の承諾方針、、、）？

P.4 あり得る義務
BPPC 方針が含むべきものは現状では全部がわかってはいません。以下は、研究者、医療情報交換、販売者の使用により発見された物です。以下は BPPC によって統合される可能性のある物についての考えです。
一般
1.

患者の使用可能な書類のうち使用者に読めない書類の存在（メタデータ）を一覧に表示するか？

2.

現場での役割を XDS 連携圏での役割に対応付ける

実装の前に
3.

特定の書類源が、特定の一箇所に特異な「正常」コ－ドを付けて書類源の書類をすべて出版する様、設定されている。たとえば特定の患者に使用されている自動
血圧計。

4.

書類に付けるコードを使用者に促す（選択用一覧表の表示）

5.

書類タイプに基づくコード

出版の前に
6.

出版するコードが通知されていることの証明

7.

書類の出版、及び・または、使用を禁止する XDS 連携圏患者プライバシポリシの
支持

書類利用の前に
8.

認識不能のコードを持つ書類を表示すべきか？

9.

ある場所で決めた「本当にそうしますか」の文言を使用者に示します。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

243

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

10. 起訴承諾方針の閲覧を許す
11. 使用者に患者に特異的な患者プライバシ方針通知書類の閲覧を許す
12. 承諾による守りを無効にするのを許すか（break glass(用事特権取得)）？

13. XDS 連携圏の書類を使用するのに、患者からあたらし承諾を必要とする。
14. XDS 連携圏の書類の出版、及び・または、使用を禁止する XDS 連携圏患者プラ
イバシ方針の支持（明示的離脱、Opt-Out としても知られる）
15. 書類上のコードが通史されたことの証明
16. 閲覧のみ許可の秘匿コードを持つ書類は、組み込んだり、コピーできない17. この文書の使用は、ATNA 緊急利用事例にならねばなりません。

P.5 動的使用例
書類は予期されるコードとともに単純に出版され、書類の使用についてのみ、書類にある
コードにもとづいて、すべての現在の患者プライバシ方針通知が評価されるべきと提言されています。このように、廃止は思う以上に動的です。

________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

244

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

用語集
Actor （実行役）: 使用例図の中の実在で、使用図のなかで活動を行いうる。活動には通信文の生成や消費がある。
ADT: 入院・退院・転院 Admit, Discharge and Trnasfer。
（訳者注: 患者登録システムの一型）
Care Delivary Organization（療養提供組織）: 広い範囲の医療施設で、個人開業医、養護
死せ悦、外来診療所、急性期入院施設、病院、などを言う。
CCOW: ANSI 認証の技術非依存の、HL7 状況管理構造（CMA）の仕様。この構造により、複数のアプリケーションが使用場所で臨床的に意味のある様に自動的に協働したり同期できます。この書類で特定された構造は、医療アプリケーション間から、臨床デスクトップとして働くパーソナルコンピュータの様な、使用現場装置へ相互運用性をもたらす基盤を樹立できます。
Community（共同体）: 共同体は、確立された機構により臨床情報を共有する目的で、共通の方針のもとに協働することを同意した施設や企業の結合です。施設や企業は HER、PHR の様などのような医療アプリケーションも主宰できます。共同体は世界規模で一意のID である homeCmmunityId で識別可能です。施設や企業は一つの共同体の一員であることを理由に、他の共同体の一員であることを妨げられません。この様な共同体は XDS 統合
プロファイルを使用して書類共有を定める XDS 連携圏であるか、内部構造が如何ようでもよい、その他の共同体であるかです。
Confidentiality Code（秘匿コード）: 値の一覧からとられた値で、対象物（たとえば書類）の機微さ、あるいは秘匿性を示します。これは HL7 が定める語彙あるいは、安全・プライ
バシ圏が定める拡張です。秘匿コードは利用制限の間に使用され、安全・プライバシ方針
からみた対象物のタイプを示します。
Context Management Registry（状況管理登録所）: HTTP 技術特異的なサービスで、HL7
状況管理役 CCOW 標準により定められ、特定のデスクトップにサービスを提供する状況管理役の事例の所在を見つけます。
Context Session（状況セッション）: 参加役アプリケーションの集合で、一個を超える対象物の状況を共有するものです。
CDA: Clinical Doccument Architeture （HL7 仕様）
CT（時刻一貫性）: 時刻表示一貫性統合プロファイルです。
XDS Affinity Domain（XDS 連携圏）: 共通の方針セットを使用して、共通の基盤である保管庫と登録所を共有し、協働することに合意した医療機関の群
Directory（索引）: ある場所の住民の名前と住居、あるいは、住民の階層を含む本。住所録。業務用名簿。
EHR-CR: EHR-CR あるいは療養提供記録は、療養提供組織の IT システムあるいは秘匿も________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

245

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________のシステムが管理する患者情報の要約で、個人開業、養護施設、外来診療所、急性期入院施設、などの広い範囲の医療施設を支えます。
EHR-LR: HER-CR により共有され、XDS 連携圏の HER-CR 間で療養を受ける患者の縦断的記録から登録所により追跡される書類です。これが HER-LR と言われます。
eMPI: 施設患者マスタ Enterprise Patient Master Index
Encounter（受診）: 患者と療養提供者との間の、医療関連サービスの提供を目的とした相互作用。医療サービスには健康状態評価も含まれます。
例: 複数科への外来受診、家庭健康支援（物理療法を含む）、入院、救急室受診、現場診療（たとえば自動車事故）、診療所受診、職業療法、電話相談
EUA: 施設使用者認証統合プロファイル Enterprose User Authentication
Expected Actions（予期される動作）:

きっかけ事象の結果、起こるべき動作。

GUID, Globally Unique Identifier: 永続的書類のような実体の識別子で、世界規模で唯一であることを保証する計算法で生成されたもの。
HIMMS: 米国医療情報管理医システム学会、Healthcare Information and Management
System Society
HIS: 病院情報システム Hospital Information System
homeCommunityId: 世界規模で唯一である、共同体の識別子。XCA で使用され、サービスの、共同体にあるデータの利用を提供する、ウェッブサービス終着点を取得するのに用いられます。
IETF: インターネット工学特別委員会 Internet Engineering Task Force
IHE:

医療機関統合Integrating Healthcare Enterprise

inetOrgPerson: inetOrgPerson [RFC 2789]対象物階層（object class）は人間に関する属性を保有する汎用の対象物階層です。これが保有する属性は典型的なインターネット、イン
トラネット索引サービスの配備に見いだされる情報の必要性に順応する様、選択されています。
Interaction Diagram（相互作用図）: データの流れと事例の順序を描いた図。
IT: 情報技術 Information Technology
JPEG: 写真専門家グループ連合 Joint Photographic Experts Group
KDC: キー分配センタ Key Distribution Center （切符発行許可切符（Ticket Grating
Ticket）とサービス切符を発行する Kerberos サーバ、RFC 1510 を参照。
）
LDAP: 軽量索引利用プロトコル（Lightweight Directory Access Protocol）は X.500 モデ
ルを使用可能とする索引の利用を提供しますが、X.500 DAP（Directory Access Protocol, 索
引利用プロトコル）プロトコルの資源要求を引きおこすことはありません。このプロトコ
ルは特に管理アプリケーションとブラウザアプリケーションに的を絞り、索引の相互作用的利用を提供します。
Local Authentication（現場認証）: ATNA 統合プロファイルでは、「現場認証」とは使用者________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

246

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

識別、認証、権威付与、の方法が現場管理者によって選択され、必ずしも IHE プロファイ
ルとは適合しません。現場の使用者名とパスワードのシステム、安全なトークンシステム、その他の現場の安全管理者が受け入れられるシステムでありえます。
Movement（移動）:受診状況のなかで患者の状態の変化を記述する事例。この構想は患者居所の移動、患者階層の変化、新しい受け持ち医、新しい指導医、新しい受診の開始、受診のおわり、などを含みます。
MPI: 患者マスタ Master Patient Index
MIRN: メディケア記録番号 Medicare Record Number
NEMA: 米国電気機器製造者連合 National Eletrical Manfacrureers Association
NTP: ネットワーク時刻プロファイル Network Time Protocol. これはコンピュータの時
計を同期させる、標準のインターネットプロトコルです。http: //www.ntp.org には、初心者から専門家レベルまでの、コンピュータ同期の方法の広範な背景書類があります。
OID: 対象物識別子 Object Identifier
PACS: 画像保存通信システム Picture Archive and Communication System
Patient（患者）: （ATNA の状況で使用されたとき）RFC-3881 は患者である人物を識別する手段を定めています。監査記録にある患者情報は、監査記録が生成された時点で患者を識別するのに使用できた情報と対応しており、後の更新を反映しません（たとえば、患者整合）。
PatientID（患者 ID）: （ATNA の状況で使用されたとき）システム内のシステムの範囲で一意である、患者識別子を有する自由テキスト。患者識別圏は監査記録を生成するシステ
ムに割り付けられるものです。監査記録にある患者情報は、監査記録が生成された時点で患者を識別するのに使用できた情報と対応しており、後の更新を反映しません（たとえば、
患者整合）。
Patient Identifier Cross-referencde Domain（患者相互識別圏）: 患者識別相互参照管理役に知られ、管理されている患者識別圏のセットからなります。患者識別相互参照管理役は異なった患者識別圏からの患者識別の別名を見つける責任があります。
Patient Iedntifier Domain（患者識別圏）:

共通の患者の識別方式を共有する一個ないしは相互接続されたシステムのセット。この様な方式では、(1) 一個の権限をもつ識別子発行
役、(2) 患者に識別子を割り付ける過程(3) 発行された患者識別子と関連する患者特性との永続的記録、および、(4) 維持の過程、が含まれます。患者識別の目標は過誤を減らすことです。
Patient Mapping Agent（患者対応付け代理役）:

CCOW が定めた要素で、別々の患者識別圏を超えて患者識別子の対応付けを提供します。
Patienht Privacy Policy Acknowledgement Document（患者プライバシ方針通知書類）:
BPPC 内容プロファイルに従う文書で、特定の患者プライバシ方針圏が定めた患者プライバシ方針を通知する患者の行動を記録します。
________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

247

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

Patient Privacy Policy（患者プライバシ方針）: 患者プライバシ方針は、患者に選択肢を与える様な方法でデータや書類の適切な使用をさらに説明します。
BPPC プロファイルは、方針の内容、あるいは、この方針を開発する方法、について一切の要求事項を課しません（方針開発のガイドについては ITI TF-1: 付録 P を参照してください）。患者プライバシ方
針は、情報を誰が利用するか、どの情報を方針で管理するか（たとえば、どのような条件
で書類をあるタイプの情報を含むと印を付けるか）、を特定します。患者プライバシ方針は、承諾の方針、不同意の方針、認証方針などであり得ます。
Patient Privacy Policy Identifier（患者プライバシ方針識別子）
Patient Privacy Policy Domain（患者プライバシ方針圏）
Patient Subject（患者主体）
PDF: Portable Document Format
職員録（Personnel White Pages, PWP）: PWP 索引権限内の職員についての情報。この情報は、医療機関全体にわたり多くの臨床、非臨床アプリケーションの間で広く使用されます。この情報は臨床業務流れを強化し（連絡先）、使用者インターフェースを強化し（使用者に親しみやすい名前や標題）、同一性を確実にします。
PIX: 患 者 識 別 相 互 参 照 統 合 プ ロ フ ァ イ ル

Patient Identifier Cross-referrencing

Integration Profile
PMA: CCOW で定められた、患者対応付け代理役（Patient Mapping Agent）要素
Principal （主宰役）: 最終使用者、アプリケーション、機械、その他の実体で、トランザ
クションのなかで要求を発する役をつとめます。主宰役はトランザクションのなかでデジ
タル識別で代表され、主宰役は異なったトランザクションで使用する複数の有効な識別を待ちます。
Process Flow Diagram（処理流れ図）: 一つの例に含まれる実行役の間の相互作用と処理の流れを図で示したもの。
PSA: 患者同期アプリケーション統合プロファイル

Patient-Synchrinized Application

Integration Profile
RID: 表示用情報取得 Retrieve Informaton for Display Integration Profile
RIS: 放射線情報システム Radiology Information System
Role （役割）: 使用例での実行役の行動
RSNA: Radiological Society of North America, 北米放射線学会
Scope（範囲）: トランザクションの短い記述
Secure Domain （安全圏）: ネットワーク、ハードウエアシステム、安全拠点、および、一組の安全方針が定められアドレスを使用できる対象物の利用を強制する、物理的環境
Secure Node（安全拠点）: 安全圏の利用方針と管理に適合する、ネットワークアドレスを使えるシステム。安全拠点はしばしば IHE 実行役を支えます。
SNTP: 単純ネットワーク時刻プロトコル Simple Network Time Protocol。これは NTP________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

248

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________の精度を低くした NTP です。プロトコルデータ野は同じですが、使用されるデータの値と計算法は精度を減らしており、性能の限られたシステムにも実装できます。
提出セット（Submission Set）: 書類保管庫に一緒に登録された、EHR システムから提供された一人の患者の一個の療養に関係する情報についての XDS 書類のセット。
SUID: スタディ事例固有 ID 。
DICOM SOP インスタンスのスタディインスタンス UID、あるいは、SOP インスタンスの集合。
TGT: 切符発行許可切符 Ticket Granting Ticket。使用者が認証を受けていることを証明する最初の信任状です。使用者認証を繰り返すのを避けるたまに使用され、サービスを利用する要求のトークンとして使われます、
Trigger Event（きっかけ事象）: 通信文の通知や処理の完了の様な、他の動作を起こす事例。
UID: 固有識別子 Unique Identifier
Universal ID: UID タイプ内の持続する固有識別子。それぞれの UID は特別に列挙された種の一つに属さねばなりません。普遍 UID はその文法規則に従わねばなりません。
Use Case（使用例）: 実行役とシステム運用の図示。
Username（使用者名）: パスワードと異なる文字列で個人識別に使用され、多使用者コン
ピュータシステム、LAN、掲示板システム、あるいは、オンラインサービスに入るときに必要とされます。User ID、uid とも言われます。
User Assertion（使用者断定）: 識別提供役が発行する、認証された主宰役（使用者、アプ
リケーション、システム）についての取得要求セット
User Subject（使用者主体）: デスクトップのアプリケーションに現在ログインしている使用者識別情報の共有を可能とする PSA が定義する主体。
UTC：世界標準時 Universal Coordinated Time。これは GMT に置き換わるものです。
国際的に認識され支持されている参照用時刻標準を定めます。
Wet Signature（紙署名）: 紙にインクでした署名
X-Assertion Provider：これは SAML 識別提供（IDP）あるいは、WS-Trust 安全トークン
サービス（STS）で、IHE ではこれ以上、特定されません。
XDS Affinity Domain Policy（XDS 連携圏方針）: XDS 連携圏の適切な使用を明確に定義する XDS 連携圏方針。この方針のなかに、公表され了解されたプライバシ承諾方針の認容できる使用のセットがあります。
XDS 書類: XDS 書類は書類保管庫に提供され書類登録所に登録可能な最小単位の情報です。
XDS 書類には、単純テキスト、書式化テキスト（たとえば、HL7 CDA 第 1 版）
、画像（たとえば DICOM）あるいは構造化され語彙コード化された臨床情報（たとえば、HL7 CDA
第 2 版、CCR）あるいは、上記のタイプの混合からなるものです。
XDS フォルダ: XDS フォルダは書類源が提出する書類とそのほかの関連する書類とを群化することを可能にします。フォルダを構成するものと、HER-CR が使用する特定のフォル________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

249

Copyright © 2013: IHE International Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

ダと関連する語彙は、XDS 連携圏の療養提供組織メンバ間での合意で決められます。
XUA: 施 設 間 使 用 者 確 認 統 合 プ ロ フ ァ イ ル

Cross-Enterprise User Assertion

Integration Profie________________________________________________________________________________
Rev. 10.0 Final Text – 2013-09-27

250

Copyright © 2013: IHE International Inc.