IHE-J-A-G0002 V1.0

1
2
3
4
5

6
7
8
9
10
11
12
13

データ入力用書式取得・提出に関する仕様
（RFD）

14
15
16
17

文書番号：IHE-J-A-G0002 V1.0
版番号：1.0 パブリックコメント

18
19
20
21
22
23
24
25
26

2016 年 11 月 4 日

27
28
29
30

一般社団法人 日本 IHE 協会

1

31

改訂履歴
日付
2016 年 8 月 27 日
2016 年 10 月 27 日
2016 年 10 月 31 日

版番号
0.1
0.2
0.3

2016 年 11 月 4 日

1.0

改訂概要
初版発行
運営委員会用ドラフト
範囲、用語および定義、シンボルおよび略語を追加
目次を整備
パブリックコメント版

32

2

目次

33

34

内容

35

1

はじめに ................................................................................................................................................ 536

2

範囲...................................................................................................................................................... 5373

用語および定義 ..................................................................................................................................... 538

4

シンボルおよび略語 ............................................................................................................................... 6395

要求事項............................................................................................................................................... 740

6

RFD（データ入力用書式取得・提出に関する仕様） ................................................................................... 8

41

付録：

42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

RETRIEVE FORM FOR DATA CAPTURE (RFD) 日本語訳 .................................................... 10

A. TECHNICAL FRAMEWORK VOLUME1........................................................................................................ 10
17.1 使用例 .................................................................................................................................................. 11

17.1.1 治験新薬臨床試験の使用例 .......................................................................................................... 11
17.1.1.2 望ましい状態 ............................................................................................................................. 1217.1.2 公衆衛生報告の使用例 ................................................................................................................. 1217.1.3 薬物監視シナリオ ........................................................................................................................ 14
17.1.4 心臓病学研究使用例 ..................................................................................................................... 14
17.1.5 放射線科学使用例－臨床意義登録 ............................................................................................... 15
17.1.6 データ解説 ................................................................................................................................... 1617.2 アクタ・トランザクション ................................................................................................................. 1717.2.1 アクタ........................................................................................................................................... 18
17.2.2 トランザクション ........................................................................................................................ 1817.3 RETRIEVE FORM オプション ................................................................................................................ 19

17.3.1 Archive Form オプション ............................................................................................................ 19
17.3.2 Clarifications オプション ............................................................................................................ 19
17.3.3 XForms オプション ...................................................................................................................... 1917.4 RETRIEVE FORM 処理の流れ ................................................................................................................ 1917.5 安全性の考慮 ....................................................................................................................................... 25

17.5.1 RFD リスク分析とリスク評価...................................................................................................... 25
17.5.2 推奨 .............................................................................................................................................. 25
B. TECHNICAL FRAMEWORK VOLUME 2 ....................................................................................................... 26
3.34 RETRIEVE FORM [ITI-34]（書式取得） ................................................................................................... 26

3.34.1 範囲 .............................................................................................................................................. 26
3.34.2 ユースケースロール ..................................................................................................................... 27
3.34.3 参照規格 ....................................................................................................................................... 27
3.34.4 相互作用図 ................................................................................................................................... 28
3.34.5 プロトコルの必須事項 ................................................................................................................. 32
3.35 SUBMIT FORM [ITI-35]......................................................................................................................... 34

3.35.1 範囲 .............................................................................................................................................. 34
3.35.2 ユースケースロール ..................................................................................................................... 35
3.35.3 参照規格 ....................................................................................................................................... 35
3.35.4 相互作用図 ................................................................................................................................... 35
3.35.5 プロトコルの必須事項 ................................................................................................................. 37
3.35.6 セキュリティに関する注意事項................................................................................................... 39

3

76
77
78
79
80
81
82
83
84
85
86
87
88
89
90

3.36 ARCHIVE FORM [ITI-36]....................................................................................................................... 39

3.36.1 範囲 .............................................................................................................................................. 39
3.36.2 ユースケースロール ..................................................................................................................... 39
3.36.3 参照規格 ....................................................................................................................................... 40
3.36.4 相互作用図 ................................................................................................................................... 40
3.36.5 プロトコルの必須事項 ................................................................................................................. 41
3.36.6 セキュリティに関する注意事項................................................................................................... 43

3.37 RETRIEVE CLARIFICATIONS [ITI-37] .................................................................................................... 43

3.37.1 範囲 .............................................................................................................................................. 43
3.37.2 ユースケースロール ..................................................................................................................... 44
3.37.3 参照規格 ....................................................................................................................................... 44
3.37.4 相互作用図 ................................................................................................................................... 44
3.37.5 プロトコルの必須事項 .................................................................................................................. 47

4

91

1 はじめに

92
93
94
95
96
97
98
99
100
101
102
103
104
105

データ入力用書式取得・提出に関する仕様（RFD：Retrieve Form for Data Capture）は、外部サーバが要求する項目に適合する様に、使用中のアプリケーション（例えば電子カルテなど）の中でデータを収集する方法を提供するものである。この RFD の枠組みを利用すると、書式が保存してあるサーバなどから書式を取得し、データを完成して、電子カルテなどから外部のサーバへデータ送信することが可能となる。
全国調査や全国登録など応用できる事例は多いと思われる。このような場合に、この RFD プロ
ファイルを利用してシステムの設計・構築やシステムのテストなどが迅速かつ効率的に行われることを期待できる。

106

2 範囲

107
108
109
110

本仕様書は、規定された書式にデータを入力し、その入力されたデータを提出する機能に関する仕様を定めたものである。

111

3 用語および定義112113

本仕様は、データ入力用書式取得・提出に関する仕様として IHE の定めた ITI Technical
Framework の中から必要なものを採用した。尚、規格そのものの詳細は、原語の英文を参照する必要がある。

本書に必要な用語および定義は以下の通りである。

用
語
Actor

Digital Imaging andCommunications in Medicine
Health Level 7
IHE Integration Statements

Integrating the Healthcare
Enterprise定義
アクタ。IHEの場合、病院業務に関連した情報を作り出し、管理し、操作する情報システムや情報システムのコ
ンポーネントをこのように呼んでいる。
略称DICOM。医療用デジタル画像とその通信のための標準規格。
略称HL7。医療情報交換のための標準規約で、患者管理、
オーダ、照会、検査報告などの情報交換を取り扱う。
IHE統合宣言のこと。IHE統合宣言は、製造者によって公開される文書で、製品におけるIHEテクニカルフレーム
ワークとの適合性を記述したもの。
医療連携のための情報統合化プロジェクトであり，医療情報の標準化へ向け、業務フローに従ったDICOM、HL7といった標準規格の適用ガイドラインを作成し、ベンダのシステムへの実装、接続テストを実施する体制を構築
している。

5

Integration Profiles

Technical Framework

Transaction

HyperText Markup Language

Extensible HyperText Markup
Language
XForms統合プロファイル。多くの医療機関において利用できる共通のシステム統合モデルであり，アクタ(Actor)とトラ
ンザクション(Transaction)で示される。ワークフロー，
コンテンツ，インフラを示すものなどがある。
テクニカルフレームワーク。IHEにおける最も基本的な文書。IHEのシナリオモデルである「統合プロファイル」の他、通信処理（トランザクション）の仕様等が記載されている。
トランザクション。IHEの場合、統合プロファイル内の各機能を提供する「アクタ(Actor)」同士の通信処理をこのように呼んでいる。
Webページを記述するためのマークアップ言語。文書の論理構造や表示の仕方などを記述することができる。
W3Cによって標準化が行われており、大半のWebブラウ
ザは標準でHTML文書の解釈・表示が行える。
Webページの記述などに用いられるマークアップ言語
であるHTML（HyperText Markup Language）をXMLの仕様に従って定義しなおした言語。
HTMLの持つフォーム機能を分離独立させ、さらに強化することを意図した仕様。

114
115

4 シンボルおよび略語

116
117
118

本書に必要なシンボルおよび略語は以下の通りである。

IHE

Integrating the Healthcare Enterprise

119



ITI

Information Technology Infrastructure

120



TF

Technical Framework

121



HL7

Health Level 7

122

DICOM Digital Imaging and Communications in Medicine

123



SOAP

Simple Object Access Protocol

124



TLS

Transport Layer Security

125



RFC

Request for Comments

126



HTML

HyperText Markup Language

127
128
129



XHTML Extensible HyperText Markup Language

6

130

5 要求事項

131
132
133
134
135
136
137
138
139
140
141
142

5.1. 適用文書
本仕様は、以下の文書に準拠するものとする。

IHE-ITI Technical Framework Volume 1 Rev 12.0
IHE-ITI Technical Framework Volume 2b Rev 12.0

5.2. 適合宣言
本仕様の適合を宣言する場合は、「IHE 統合宣言書」を発行することとする。その書式と内容は、
IHE-ITI Technical Framework Volume 1 Rev 12.0 Appendix C を参考にすること。

7

143
144

6 RFD（データ入力用書式取得・提出に関する仕様）

145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167

データ入力用書式取得・提出に関する仕様（Retrieve Form for Data Capture：以下 RFD）は、外部システムの要件を満たすために、ユーザが所有する現在のアプリケーション内でデータを収集するための方法を提供する。RFD はフォームの提供元（form source）からフォームを取得し、フォームの表示と入力を行い、受信アプリケーションへ表示アプリケーションからインスタンスデータの返信を行うことに対応している。また、RFD は以前に取得したデータを修正するためのメカニズ
ムも提供する。
医療機関のサイトが患者ケアを文書化するために電子カルテ（EHR）を使用する場合、EHR は
医療機関の担当者が通常利用するアプリケーションとして動作している。外部機関は、提供施設における EHR のデータベース内に存在するデータと EHR のユーザによる追加入力されるデータを要求する。RFD は EHR のユーザが通常利用するアプリケーションである EHR から離れることなく、外部機関からのデータ入力用フォームを取得し、フォームにデータの入力を行い、外部機関にデータを提出することを可能にする。プロファイルは、取得したデータについての要点を明確にする必要がある場合の指標と、データを変更できるメカニズムの提供を外部機関に行うことも可能である。
RFD の多くの潜在的な用途では、（固定）フォームからホストアプリケーションのデータベース
により動的に事前入力されたフォームを望んでいる、それがフォームの適切なフィールドに内にセットされたホストアプリケーションのデータベースの値と共に提供されるフォームである。 RFD
は、自動的なフォームの集団を許可し、これを実現することが可能となる一般的なメカニズムを提供する。
図 6.1-1 に、RFD に直接含まれるアクタとこれらの間の関連するトランザクションを示す。他の統合プロファイルを通じて間接的に利用されるアクタは含んでいない。

 Archive Form [ITI-36]
Form Filler

Form Archiver

Retrieve Form [ITI-34]

Retrieve Clarifications[ITI-37]  Submit Form [ITI-35]

Form Processor
Form Manager

168
169
170

Form Receiver

図 6.1-1: RFD のアクタ図

8

171
172
173
174
175

表 6.1-1 に、RFD に直接含まれるアクタのそれぞれに対するトランザクションを示す。この統合プ
ロファイルが使用可能と主張するには必須トランザクション（"R"と表記）を実行できなければならない。"O"と表記されたトランザクションはオプションである。この統合プロファイルに定義され、実装上選択可能なオプションの全ての一覧は ITI TF-1: 17.3 にある。

176

表 6.1-1: RFD 統合プロファイルのアクタとトランザクション
ActorsForm Filler

Form Manager

177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196

Transactions

Optionality

Section in
Vol. 2Retrieve Form [ITI-34]

R

ITI TF-2b: 3.34

Submit Form [ITI-35]

R

ITI TF-2b: 3.35

Archive Form [ITI-36]

O

ITI TF-2b: 3.36

Retrieve Clarifications [ITI-37]

O

ITI TF-2b: 3.37

Retrieve Form [ITI-34]

R

ITI TF-2b: 3.34

Retrieve Clarifications [ITI-37]

R

ITI TF-2b: 3.37

Form Receiver

Submit Form [ITI-35]

R

ITI TF-2b: 3.35

Form ArchiverArchive Form [ITI-36]

R

ITI TF-2b: 3.36

Form Processor

Retrieve Form [ITI-34]

R

ITI TF-2b: 3.34

Submit Form [ITI-35]

R

ITI TF-2b: 3.35

Retrieve Clarifications [ITI-37]

R

ITI TF-2b: 3.37

本統合プロファイルの詳細については、以下を参照のこと。
IHE-ITI Technical Framework Volume 1 Rev, 12.0
17. Retrieve Form for Data Capture (RFD)
IHE-ITI Technical Framework Volume 2b Rev, 12.0
3.34 Retrieve Form
3.35 Submit Form
3.36 Archive Form
3.37 Retrieve Clarifications
IHE-ITI Technical Framework Volume 2x Rev, 12.0
Appendix V Web Services for IHE Transactions
Appendix W Implementation Material
これらの日本語訳を以下に付録として示す。

9

197

付録：

198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242

A. Technical Framework Volume1

Retrieve Form for Data Capture (RFD)

日本語訳

データ入力用書式取得・提出・管理に関する仕様（Retrieve Form for Data Capture：以下 RFD）は、
外部システムの要件を満たすために、ユーザが所有する現在のアプリケーション内でデータを収集するための方法を提供する。RFD はフォームの提供元（form source）からフォームを取得し、フォームの表示と入力を行い、受信アプリケーションへ表示アプリケーションからインスタンスデータの返信を行うことに対応している。また、RFD は以前に取得したデータを修正するためのメカニズムも提供する。
医療機関のサイトが患者ケアを文書化するために電子カルテ（EHR）を使用する場合を考えてみる。この場合では、EHR は、プロバイダの担当者のためにローカル・ホーム・アプリケーションとして動作する。いくつかの契約上の取決めを介して仮定された外部機関は、プロバイダの EHR のデータベース
内に存在するものと、EHR のユーザによる追加データ入力が必要なデータを要求する。 RFD は EHRのユーザがローカル・ホーム・アプリケーションである EHR から離れることなく、外部機関からのデータ取得用フォームを取得し、フォームに入力を行い、外部機関にデータを返すことを可能にする。プ
ロファイルは、取得したデータについての要点を明確にする必要がある場合の指標と、データを変更できるメカニズムの提供を外部機関に行うことも可能である。
RFD の多くの潜在的な用途では、（固定）フォームからホストアプリケーションのデータベースにより動的に事前入力されたフォームを望んでいる、それがフォームの適切なフィールドに内にセットされた
ホストアプリケーションのデータベースの値と共に提供されるフォームである。 RFD は、自動的なフォームの集団を許可し、これを実現することが可能となる一般的なメカニズムを提供する。ただし、プロファイルは、コンテンツの問題、標準的な語彙上の使用されない残在および意味としての相互運用性の他の黙認者について述べることはない。特定のドメイングループ［臨床試験、医薬品の安全性、生物学的監視（bio-surveillance）］はコンテンツの仕様を提供することまたは RFD 内で動作する既存のコンテンツ規格の評価と推奨を行うことにより RFD の上に構築される。 RFD は、インフラストラクチャプロファイルとしてドメイン固有のコンテンツ規格を統合した場合、相互運用性のレベルがはるかに高くなるだろう。
RFD プロファイルは、データを修正するために医療機関が取得し有効化したデータの問題を示すことが可能になる一般的なポーリングメカニズムを外部機関に提供する。プロファイルは、このような修正を実現するために使用されるメカニズムや要求されるコンテンツを規定していない。
このプロファイルでは、外部機関はそのドメインに適切なスキーマのデータ取得フォームを提供する。
プロファイルは、表示するアプリケーションが行うべきであるフォームを完成させるために必要な指示が渡される完全な機能のフォームを持ってくるといった作業を最小限にすることを意図している。RFDは完成したフォームのコピーを保存することにも対応している。
RFD は、構造とデータ取得のために使用されるフォームのコンテンツの両方を扱う業界標準を活用する機能を提供している。HL7 の個別症例安全性記録（ICSR）と CDISC のオペレーショナルデータモ
デル（ODM）は例示を提供している。
RFD プロファイルによって提供されるインフラストラクチャは、多数のドメイングループによって利用することができ、以下のドメイン固有のユースケースは、RFD が行うことが可能な用途の多様性を示している。

10

243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289

17.1 使用例
以下の使用例は、このプロファイルがどのように様々な分野で使用される可能性があるかを示している。
RFD プロファイルはこれらの使用例全てを可能にする。
それはすべてが実装されているわけではない。
RFD の使用法とデータオブジェクトのためのルールの両方を規定する特定のプロファイルは、将来的にはドメイン固有の IHE プロファイルとして実際に規定されることが期待されている。
17.1.1 治験新薬臨床試験の使用例
臨床試験の使用例のための設定として、患者診療と平行して臨床研究が行われることが医師の慣行となっている。Holbin メディカルグループは、専門が様々な 100 名を超える医師を雇用し、多数の施設を有する実地診療を行う機関である。Holbin の最高経営責任者（CEO）は製薬会社が主催する臨床試験のための施設研究者として参加するように医師を奨励している； Holbin は大部分が登録看護師（RN）
である 12 名の研究コーディネータと事務・データ入力を行うサポート担当者を含む研究部門が臨床研究活動を支援する。Holbin メディカルグループは電子カルテ（EHR）と臨床試験活動を文書化するためのスポンサーが提供する電子データ収集（EDC）システムを複数使用している。
（私たちの目的では、
EHR は主となる施設における患者診療の文書化と患者診療情報の取得を行うための任意のアプリケー
ションとする。そのため、（ここで言う EHR は）厳密な意味では EHR とは言えない現在インストール
されている有用な多数のシステムに及ぶものも含まれるが、このアプローチでは有効である。
）
Holbin の臨床研究への関与は、研究スポンサーから提案要求を研究部門が受け取ったときから始まる。
研究コーディネータである Patricia Zone 登録看護師は、RFP を事業可能性と臨床的妥当性に関して評
価し、スポンサーに返信する要求された書類を提供する。#1234 として識別された臨床試験のための施設として選ばれ、必要な規制に関する書類をスポンサーに提出した後、主任研究者となった医師とその他の研究員はスポンサーからプロトコル固有のトレーニングを受ける。治験準備期間の間に、Patricia
はこのプロトコルのための場所のセキュリティに関する適切なシステム化、研究プロトコルに記載されている基準および除外基準に従った被験者として参加する患者の募集、患者の来院スケジュールの立案、データ収集とデータ入力の管理および付随する経理業務の全ての実施を確実に行えるようにする。
Patricia は Holbin の患者である Corey Jones に臨床試験の参加に関して連絡を行い、Corey は被験者として参加することに同意します。Patricia は EHR の患者インデックスを使用して Corey を臨床試験#1234 の被験者として EHR に登録する。
彼女は EHR のスケジューリングモジュールを使用して Coreyの検査来院日程を決め、臨床試験#1234 に関連する来院のフラグを立てる。準備段階の後、施設は臨床試験を開始し、臨床試験特有の記録を作成する。
この使用例は、現在の状態と望ましい状態のシナリオに続いていき、RFD の実装前と後について、患者の臨床試験の来院中における EDC 技術を利用したデータ収集に関する説明する。

17.1.1.1 現在の状態
Corey Jones は予定された臨床試験のためにクリニックに到着し、問診のために Patricia Zone と会う。
Patricia は EHR にログインし、簡潔な入力をして来院記録を作成する：－「Jones さんは治験#1234に関係する臨床試験の来院のために入室する。」Patricia は Jones さんの問診、観察を行い、原本である紙の書類に彼女の観察結果を記録する。彼女は EHR で最近の検査結果を閲覧し、症例報告書（CRF）に記録する。EHR は書類を完成させるために必要なデータの一部しか提供しないので、残りは問診と観察から得ることになる。
（EHR から得ることが可能な臨床試験のために必要なデータの割合の推定値
は 5％から 40％で変動する。最良の場合であっても、EHR は一般的に研究プロトコルに必要なデータのサブセットしか取得しない。
）

11

290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334

完成した原本の書類はデータ入力担当の Bob に渡されます。Bob は治験#1234 に属する CRF であると認識し、治験#1234 用の EDC システムを選択します。このシステムはスポンサーから供給されたノートパソコン上にあるものでも良いし、インターネットを経由してスポンサーの EDC システムにブラウ
ザセッション経由で接続してアクセスしても良い。彼は既製の 3 リングバインダを取り出し、この特定システムの使用方法の指示を知るために彼の”虎の巻”を参照する。彼は固有のユーザ名とパスワードを使用して EDC アプリケーションにログインし、その治験来院のための正しい電子症例報告書（eCRF）にデータを入力する。原本の書類が処理されると、Bob は治験の永久的な原本記録の一部として収納ボックス1に保管される（連邦規則 21 CFR 312: 62 の要求事項を満たすために）。
治験#1234 に加え、Bob は 8 つの追加 EDC システム、5 台の専用ノートパソコンと 3 つのウェブベースシステムにデータ入力を行います。ウェブベースの EDC システムは机上スペースを節約するが、Bobは彼の”虎の巻”の保存場所である 3 リングバインダが必要となる。
特定の治験からのデータを確認する雑務は、対応するノートパソコン固有のログイン手続きとデータ取得フォームへの入力が含まれるので、Bob はシステムのこの扱いにくい一連の操作を行うことにとても苛立ちを覚えている。Bob は誠実な従業員で、彼の仕事に遅滞はない。しかし、多くの他施設のデータ
入力担当者は、データを入力するまでの期間の CRF を保持しており、月 2 回のデータ入力もしくは被験者が来院する一週間前にデータを入力するかもしれない。
17.1.1.2 望ましい状態
Jones さんが来院し、Partica は EHR にログインして Jones さんの記録を取得し、予定された治験用来院であることを認識します。準備期間中に患者識別とスケジューリング手順を行っていたので、EHRは Jones さんを治験#1234 の被験者と認識し、RFD を使用する治験#1234 の EDC システムから電子症例報告書を要求する。治験が十分複雑であれば、取得したフォームは Partica が選択するために EDCシステムで関連するフォームのリストを提示してもよい。正しいコンテキストが EHR と EDC の間で確立されると、Patricia は EHR アプリケーションの臨床研究のタブを選び、適切なフォームが表示される。EHR は Patricia の資格情報を確認し、彼女にフォームを閲覧する権限があるかの認証を行ってからフォームを表示する。データ収集フォームは EDC がこの来院に与えるものと本質的に同じ書式であるが、EHR のユーザーインターフェースと似た見かけで提示されるかもしれない。虎の巻の使用はまだ必要かもしれないが、洗練されたフォームは書式の記述方法の情報を提示するべきである。
Paricia は Jones さんの問診を行い、臨床試験フォームにデータを入力する。EHR のデータベースからのデータは適切なデータフィールドに予め入力することもできる（編集チェックを組み込むことで）。
フォームが完成したら、Patricai は「提出」ボタンを押し、EHR は完成したフォームを EDC システムに RFD を使用して返信する。書類のコピーは施設の治験の永久的な原本記録の一部として臨床試験保管庫に保存される。
17.1.2 公衆衛生報告の使用例
17.1.2.1 公衆衛生シナリオ１
17.1.2.1.1 現在の状態
Smith さんは消化器の症状で地域病院の救急部を受診した。医療従事者は試料を検査室に送った。検査室はクリプトスポリジウムを検出した。検査室職員は毎週必要な公衆衛生報告のために検査用データベースを照会する。症例が同定され、検査情報システムからの情報を公衆衛生報告書に写し、印刷と公衆衛生当局への送信を行う。公衆衛生当局は管轄内の医療機関から提出された報告書を閲覧し、複数のクリプトスポリジウム症例が地域の病院で発生していることを認識する。追加症例を監視する様に地域の1

定義は http: //www.archivisits.org/glossary/term_detaiks.asp?DefinitionKwy=1193 を参照。

12

335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381

医療機関に通告が通達されるイベントが発行される。感染のあった地域に供給している水が検査され、結果に応じて対応が行われる。しかし、紙ベースの処理によって検出プロセスに遅れが発生したため、クリプトスポリジウム感染症の多くの追加例が発生してしまった。
17.1.2.1.2 望ましい状態
Smith さんは消化器の症状で地域病院の救急部を受診した。医療従事者は試料を検査室に送った。検査室はクリプトスポリジウムを検出した。検査室システムは、この結果が公衆衛生報告を必要とするものと認識し、検査システムで結果の検証がされるとすぐに PHIN 規格を使用して州の DOH（厚生局）に送信した。追加もしくは代わりに、フォームはバイオウォッチ（バイオ兵器早期警戒）公衆衛生システ
ムから RFD プロファイルを使用して取得される。症例報告書式が提供者に提示され、EHR が事前にデータをマッピングする。医療提供者は、残りの補足情報を入力し、このデータを公衆衛生当局へ電子的に提出する。公衆衛生当局は管轄内の検査機関や医療機関から多数の電子報告を受け取った。追加の症例を監視するために、地域の医療機関と検査機関に通告が通達される。地域に供給している水が検査され、結果に応じて対応が行われる。処理の自動化で早期発見が可能となり、地域のさらなる疾病は最小限に抑えられた。
17.1.2.1.3 炭疽菌、鳥インフルエンザシナリオ: 仮診断や患者”問題”に基づいた疾患看視炭疽菌：患者が急速に進行する呼吸器症状で救急科（ED）を受診した。喀痰のグラム染色でグラム陽性桿菌が見つかり、胸部 X 線写真では縦隔の拡大があり、患者の状態は急速に悪化した。検査室での痰培養では炭疽菌が疑わしいとの結果だった。州の健康省（DOH）は病院と接触し検体を確認のため送付した。いったん炭疽菌と確認されると、州 DOH は適切な地区、地域、州および連邦当局（たとえば、
CDC, FBI, USAMRID[米軍感染症研究所]）に通知し、さらに、地区の病院、療養提供者、メディアに通知します。
（感染確認の後には、生物テロリストのシナリオがあります。以下のインフルエンザのシナリオでもおそらく同じことがおきます）
追加の症例の可能性が通知されると、急速に進行する呼吸器症状の患者には、ED は痰の STAT グラム
染色と、正側の胸部 X 線写真を、それぞれ施行します。グラム陽性桿菌が存在すると、内部および外部の（疾病）監視レポートのため、検査システムに直接入力されるか、指定された救急室（ER）職員により CIS（臨床情報システム）の患者 ADT 画面の特定のデータフィールドに入力されます。胸部写真の迅速読影で縦隔拡大があると、指定された職員（たとえば放射線技師）が医師に代わって、ADT 画
面の特定のデータフィールドに入力されます。これらデータフィールドに値が入力されると、現場を管轄する公衆衛生生物監視システム（BIS）に対する情報のトランザクションが、吸入炭疽菌感染症と仮診断されたとして行われます。BIS は複数箇所からのデータを集積し、仮あるいは確定診断された炭疽
菌感染症の発生場所、起源、広がりを提示します。
インフルエンザ: 病院近隣の医師、ED 医師はウイルス感染を疑わせる呼吸器症状患者の増加を知りますが、周囲の病院では同様な症状患者の増加がありません。インフルエンザ A/B 迅速テストは多くの患者で陽性であり、インフルエンザ流行が地域に広まっています。呼吸器由来検体の培養は 24 時間では細菌が陰性でインフルエンザ A ウイルスが陽性でした。患者間の相互接触と死んだ鶏とから、AH5N1が疑われます。
すべての検体は州の DOH 可及的速やかに同定のため送られます。州の検査室で AH5N1と同定します。上記と同様の経緯です。健康局から現地の療養提供者へ通知が流布されたあとの経緯は、仮診断の情報が公衆衛生 BIS へ伝えられるのと同様です。上記のいずれのシナリオでも、仮診断を集める汎用的方法は、オーダ発行、医師、看護に使用する CIS の日常運用の一部として、標準化された「問題」用語（SNOMED 使用）を選択する方法です。
上記二つのシナリオの違いは、炭疽菌の例が症候群（重症の呼吸器症状と胸部 X 線写真での縦隔拡大: こ
れには放射線検査監視と ED と検査室での相互参照が必要で複雑）にもとづいた監視であることです。

13

382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428

17.1.3 薬物監視シナリオ
Cramp 医師は外来で患者を診察し、電子健康録（EHR）を利用して、患者が新しいスタチン薬の一種を服用していることを知ります。診察で患者のふくらはぎの筋力低下を見つけ、医師はスタチンの副作用と気づきます。診断のため総クレアチニンキナ－ゼ検査をオーダします。
17.1.3.1 現状
Cramp 医師は EHR を閉じて、インターネット閲覧ソフトにより http: //fda.gov/medwatch/を開きます。
FDA 様式 3500「臨床診療のなかでたまたま気が付いた有害事象の自発的通報」を持ってきます。案内
ページや記入法のページを経て、実際の様式の最初のページに到達します。最初のページでは、患者識
別子、発症時年齢または誕生日、体重を入力します。次のページには 7 項目あります。事例の分類、転記の分類、発症日、通知日、記述、関係のある検査所見、その他の関連のある病歴（最後の 3 つは文章入力）、です。3 頁目、4 頁目は製品の詳細を入力します、以後同様です。
17.1.3.2 望ましい状況
Cramp 医師は上記の様に患者を診察して EHR を利用します。問題を発見すると、EHR のインターフ
ェースから”有害事象報告”ボタンを押して FDA 様式 3500 を表示します。様式の患者基本情報欄はすでに埋められています。製品名は、EHR で操作している一部なので、適切な欄に自動的に入力されます。
Cramp 医師は様式の空欄を埋めて、直接 FDA Medwatch へ投稿します。
RFD は Medwatch から様式を取得し、表示し、FDA への様式返送を行います。このプロファイルは
EHR が様式のコピーを保持しているか、HER からデータを予め取得しておくか、については記述しないことに注意してください。単に、EHR を使って、表示し、記入を完成し、返送することが重要です。
EHR とその施設は、EHR のデータベースに様式のコピーを保存すると決めるかもしれませんが、これはこのプロファイルの拡張であり、必須ではありません。
17.1.4 心臓病学研究使用例
17.1.4.1 心臓病使用例 1－国、州、地域データ登録
いくつかの法制度では特定の心臓検査の登録を（例えば、血管形成術と心臓手術はニューヨーク州で、植え込み型除細動器は Medicare 患者では米国全体で）必須としています。さらに多くの施設は自主的に地域あるいは国のデータ登録、特に NCDR National Cardiovascular Data Registry に参加しています。
一人の心臓病患者のデータを複数の登録所に提出することができます。したがって、複数の提出を行う
ため複数のデータ収集を同時に行うことが有用で、データを用意する看護師が患者の医療記録の一回の閲覧でそれぞれの登録に関係するデータをすべて抽出できるようにします。さらに医療記録は実際には複数の電子システムや紙記録システムに分散しているので、複数の提出の用意のために繰り返し記録を見る手間は最小化されねばなりません。
心臓病関連のデータ登録への提出には大部分で、数回の患者受診に由来するデータが必要です。例えば
NCDR は診断心臓カテーテルを受けたのち経皮的冠状動脈治療（PCI）をうけた患者のデータを集めています。患者が ST 上昇型心筋梗塞で救急処置室（ER）を受診したとき、心臓カテーテル検査では NCDRが要求するデータのほんの一部分しか集まりません。以下のデータが NCDR データセットを完成するのに必要です: 以前の CABG 施行日、以前の PCI 施行日、ER 到着時刻、基礎となる検査所見（BUN、クレアチニン）、患者病歴からの情報（冠状動脈疾患の家族歴、卒中の既往、肺や腎臓病の有無、など）、測定された PCI 前の心駆出率、QCA（定量的冠状動脈造影）所見、使用した機器の目録（バーコードを含む）、および、投与した薬品、のデータです。
このため、提出の準備はそれぞれの受診のたびに段階的に増やすように行うか、後でまとめて一度に行うかを決めねばなりません。患者がどのような処置を受けるかがあらかじめ定まっていないので、どの

14

429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476

提出書式にデータを入れるかが最初の受診ではわからないため、段階的登録には問題があります。純粋な後日一括登録も問題があります。データが生成された時に記録するほうが、あとでその記録を探すよ
りも良いのです。
患者の Carl Cardiac は胸痛で救急科（ED）を受診し、心電図と病歴により、診断と治療のため心臓カテーテル室へ運ばれました。PCI 最中に、事態がゆっくり進みます。血管形成バルーンを膨らましてい
る時期に、技師の Ted Tech は州および国の血管形成術登録書式を forms repository から呼び出して心臓カテーテルシステムに読み込み、この症例に関連するデータを入力します。検査後の清掃の間に、彼は知っている範囲の情報をすべて入れ、一部が記載された登録書式を forms repository へ返します。
月末に看護師の Nancy Nurse はその月のカテーテル患者の登録データ収集を完成させる業務を割り付けられています。彼女はカテ患者の一覧を取得し、それぞれの患者の一部にデータが入った書式を選びだします。Carl の名前を選んだときは、Ted が一部のデータを入力した書式を引き出し、Carl の臨床検査結果、カテ検査報告書、CCU 看護記録、退院サマリ、を入手します。彼女は登録書式の残りを埋め、完成した書式を forms repository に戻します。
四半期の終わりに、Adele Admin は四半期の間の完成した国登録用の登録書式を保管庫から取得する特別なアプリケーションを使用して、提出に備えます。彼女は州の登録書式を処理するアプリケーション
で同様の業務を行います。
17.1.4.2 心臓病使用例 2－実施成績測定
心臓病での主要な問題は選定された検査を監視して診療の質を向上させることです。ACC, AHA, CMS,JACHO, AHRQ の間には、ST 上昇および非 ST 上昇成人心筋梗塞の新 ACC/AHA 臨床実施成績測定の様な、実施成績測定を開発し使用する強力な協力規定があります。
この様な実施成績測定には登録へのデータ収集に似たデータ収集が必要です。しかし、ある期間でのデータ収集のあとに、全人口に対するさらなる解析が行われ、報告された測定値についての適切な母集団を得なければなりません（すなわち、ある種の患者は後方視的に母集団データから除かれねばなりません）。
17.1.5 放射線科学使用例－臨床意義登録
癌患者管理での PET 画像の意義を評価する努力の一部として、米国 CMS（Centers for Medicare andMedicaid Service）はいくつかの保険償還されない検査について、研究データの、米国放射線専門医会が www.cancerpetregistry.org で運営する NOPR（National Oncologic PET Registry）への登録を前提に、保険償還を行うことにしました。
この使用例には、ある患者検査に対して提出せねばならない書式のシーケンスと医療費請求との重複が含まれます。
PET 施設は NOPR に登録せねばなりません。NORP は登録施設に限定されること、保険償還は完全なデータ提出によることのため、PET 施設が一義的な責任をおい、すべてのデータの提出に直接利用ができます。患者を紹介した医師は NOPR を利用できません。
患者の Paul Positron は胃癌の適用（あるいは NOPR に参加することによってのみ保険金が支払われる
適用）で受診しました。彼の医師、Jones 先生は NORP 参加施設の PET-Pro へ紹介しました。PET-Pro
は Jones 先生から患者基本情報を得て、この情報を NOPR にインターネット用の書式で送付します。
この時、登録症例番号が NOPR により割り付けられます。

15

477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523

いったん症例番号が生成されると、NOPR は Jones 先生に、症例に特異的な臨床上の詳細事項を記入せねばならない、PET 検査前書式を電子メールで送ります。書式は NOPR データベースの入力用に PET－Pro に PET 検査日の深夜までに転送されます。
PET 検査前、あるいは、Paul が PET 検査のため到着したとき、PET-Pro は彼に ACR IRB が承認した
標準 NOPR 患者情報シートを渡します。Paul は必要なら直接 NOPR に連絡できます。Paul は NOPR
承認を PET 施設の職員に、PET 検査当日、あるいは PET 検査完了の 2 営業日以内に、言葉で示します。書面による承諾は必要ではありません。PET-Pro は患者が承諾しなかった、あるいは NOPR の将来の研究に自身のデータの使用を認めなかった場合には、これを PET レポート書式に記します。
いったん PET が終了し、結果が報告されると、PET-Pro は検査完了書式とレポート書式（Jones 先生へのレポートも含みます）を NOPR に提出します。
NOPR は Jones 先生に、完成するように PET 検査後書式を電子メールで送ります。この書式は PETの意義に関連する情報を集めます。
これには ACR‐IRB 承認済みの紹介医情報シートも含まれており、
NOPR の将来研究への回答の使用を許可するか否かの指示があります。PET 検査後書式は完成され、
PET-Pro へ転送され、さらに PET 検査から 30 日以内に NORP データベースに入力されねばなりません。
NORP データベースは症例のすべてのデータが入力されたので施設は PET 検査を CMS へ請求できると通知します。PE-Pro は NOPR インターネットページで使用可能な PET Facility Reporting Tools を使用して、いつでも患者の状態を確認できます。
17.1.6 データ解説
治験主催組織が調査して必要なら訂正するデータを目立たせる、解説処理の必要があります。これらは、主催組織が発動するチェック（編集チェック）で見つけられ、従前に提出したデータと関係がある解説、訂正、あるいは検証のために主催組織により問合せられます。従前に提出したデータについての問い合
わせは要望により EHR システムに提供されます。解説・訂正・検証のための問合せが存在することは、
EHR に自動通知されないことに注意してください。編集チェックを行う主催組織と協業を行うときには、定期的に確認の要求を行うのは EHR にまかされています。提出されたデータに対してこのような縦断的編集チェックを行う使用例は多くはありません。
17.1.6.1 現状－問合せ処理
eCRF に組み込まれた編集チェックは正確で完全なデータ取得を容易にします；しかし治験の過程で、一部のデータには解説、訂正、あるいは検証が施設による閲覧が必要となることが多いです。データ管理者がデータを（認められた認証手続き下でのシステムあるいは手動で）閲覧するとき、欠落、不完全、
あるいは、矛盾の可能性のあるデータ（例えば、頭痛患者にペニシリンが処方されたとの施設レポート）
を見つけます。データ問い合わせが EDC システムにより生成され、研究コーディネータによる解説・
訂正・検証のため、施設に送り返されます。問合せのそれぞれで、コーディネータはデータ要素が最初に記載された元記録を参照し、元データと問い合わせたデータとを比較せねばなりません。時に、元データが不完全な場合（例えば、薬剤をやめた日）には、施設は患者に連絡を取ります。データの解説はコーディネータにより元記録の中に記載されます。元データに誤りがあると決まったら、GCP ガイド
ラインにしたがって、元の記録の中で訂正が記載されます。コーディネータは次に、EDC システムで問合せに応えて、監査証跡で取得した元記録のあらゆる更新の理由を提供します。データ管理者は更新と応答を閲覧し追加の情報が無ければ、問合せを閉じます。
17.1.6.2 将来－問合せ処理

16

524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541

HER のある治験に特有の書式と eCRF を組み込んだ編集チェックは正確で完全なデータ取得を容易にします；しかし治験の過程で、一部のデータには施設によって解説、訂正、あるいは検証の閲覧が必要となることがあります。
データ管理者がデータを（認められた認証手続き下でのシステムあるいは手動で）閲覧するとき、欠落、
不完全、あるいは、矛盾の可能性のあるデータ（例えば、頭痛患者にペニシリンが処方されたとの施設
レポート）を見つけます。データ問い合わせが主催組織システムにより生成され、研究コーディネータ
による解説・訂正・検証のため、施設にむけて用意されます。EHR 研究コーディネータは、問合せに応えるため、EHR データを参照する EHR システムを通してデータ問合せを取得し閲覧します。時に、元データが不完全な場合（例えば、薬剤をやめた日）には、施設は患者に連絡を取ります。必要ならコーディネータは EHR システム内のデータに加えた解説を記録し、問合せへの返答と、あらゆる更新を主催者システムと研究者施設保管所に送ります。問合せへの応答には、EHR システム、主催者システ
ム、研究者施設保管所の監査証跡の一部に含まれる変更の理由を含みます。主催者側のデータ管理者は応答を閲覧し主催者システムを更新し、追加の情報が無ければ、問合せを閉じます。
17.2 アクタ・トランザクション
図 17.2-1 に、RFD に直接含まれるアクタとこれらの間の関連するトランザクションを示します。他の統合プロファイルを通じて間接的に含まれるアクタは示されていません。

 Archive Form [ITI-36]
Form Filler

Form Archiver

Retrieve Form [ITI-34]

Retrieve Clarifications[ITI-37]  Submit Form [ITI-35]

Form Processor
Form Manager

542
543
544
545
546
547
548
549
550

Form Receiver

図 17.2-1: RFD のアクタ図
表 17.2-1 に、RFD に直接含まれるアクタのそれぞれに対するトランザクションを示します。実装がこの統合プロファイルが使用可能と主張するには必須（"R"と表記）のトランザクションを実行できねばなりません。"O"と表記されたトランザクションはオプションです。この統合プロファイルに定義され、実装が選択可能なオプションの全ての一覧は 17.3 にあります。

Table 17.2-1: Retrieve Form for Data Capture Integration Profile - Actors and Transactions
ActorsForm Filler

Transactions
Retrieve Form [ITI-34]

17

Optionality

Section in
Vol. 2R

ITI TF-2b: 3.34

Actors

Optionality

Section in
Vol. 2

Submit Form [ITI-35]

R

ITI TF-2b: 3.35

Archive Form [ITI-36]

O

ITI TF-2b: 3.36

Retrieve Clarifications [ITI-37]

O

ITI TF-2b: 3.37

Retrieve Form [ITI-34]

R

ITI TF-2b: 3.34

Retrieve Clarifications [ITI-37]

R

ITI TF-2b: 3.37

Form Receiver

Submit Form [ITI-35]

R

ITI TF-2b: 3.35

Form ArchiverArchive Form [ITI-36]

R

ITI TF-2b: 3.36

Form Processor

Retrieve Form [ITI-34]

R

ITI TF-2b: 3.34

Submit Form [ITI-35]

R

ITI TF-2b: 3.35

Retrieve Clarifications [ITI-37]

R

ITI TF-2b: 3.37

Form Manager

551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585

Transactions

17.2.1 アクタ
17.2.1.1 Form Manager
Form Manager は Form Filler に Retrieve Form にもとづき、書式を供給します。ある場合には、Form
Filler は単に蓄積した書式から書式を返送するだけですが、他の場合には、Retrieve Form でもたらされた状況の情報にもとづいて、書式を選択したり、組み上げたりします。さらには、Form Archiver についての追加の情報を Form Filler が提供するか否かにより、書式の蓄積から取得した書式を変更した
りします。Form Manager は書式を取得する要求に答えて、書式とともに書式インスタンス ID を返すことができます。
17.2.1.2 Form Filler
Form Filler は Form Manager から、必要に応じて必要なとき書式を取得します。
書式を要求するとき、Form Filler は、Form Manager が使用できるように、事前に書式の欄に入れておく xml データの提供による EHR 状況情報と、さらに、書式の選択を容易にするワークフローのデータも、オプションで、要求に加えて送ります。書式インスタンス ID は事前に提供されたデータの使用を決めます。
Form Filler は Form Archiver アクタを指定することができます。Form Filler に指定された Form
Archiver は、Form Manager が指定する Form Archiver に付け加えられます。
17.2.1.3 Form ReceiverForm Receiver は、Form Filler からの、完成された、あるいは、部分的に完成された書式インスタン
スデータ（forms instance data）を受領し処理します。Form Receiver の処理は、統合プロファイルの範囲外です。
17.2.1.4 Form Archiver
Form Archiver は完成された、あるいは、一部完成された書式インスタンスデータ（forms instancedata）を受けとり、これを保存の目的で蓄積します。
17.2.1.5 Form Processor
Form Processor は、統合された Form Manager と Form Receiver で、これらのアクタのすべてのトラ
ンザクションとオプションを使用可能とします。
17.2.2 トランザクション
17.2.2.1 Retrieve Form(書式取得）

18

586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611

612
613
614
615
616
617
618
619
620
621
622
623
624
625

Retrieve Form トランザクションは、Form Manager から Form Filler へ書式識別子を伝えます。この
トランザクションではオプションで Form Filler が Form Archiver を指定できます。状況情報とワークフローを含む追加情報が要求とともにもたらされることがあり、要求された書式の選択と事前の書式への値入力を容易にします。割り当てられた書式識別子の値により、書式の書式が定まります。書式識別
子の割り当てはプロファイルには定めませんが、Form Filler と Form Manager との間に必要な設定作業の一部として割り付けが行われます。
17.2.2.2 Submit Form（書式提出）
Submit Form トランザクションは、Form Filler が書式インスタンスデータ（form instance data）をForm Receiver に提出できるようにします。
17.2.2.3 Archive Form
Archive Form トランザクションは、Form Filler が書式インスタンスデータ（form instance data）をForm Archiver に提出できるようにします。
17.2.2.4 Clarifications Retrieve (Clarifications 取得）
Clarifications Retrieve トランザクションは、Form Filler が Form Manager、あるいは、
Form Processor
から任意の組織の Clarifications 書式の一組を要求できるようにします。割り付けられた組織識別子の値により、Clarifications 書式の命名されたオプション書式が決まります。組織識別子の割り当てはプ
ロファイルには定めませんが、Form Filler と Form Manager との間に必要な設定作業の一部として割り付けが行われます。
17.3 Retrieve Form オプション
この統合プロファイルのアクタごとに、選択可能なオプションを、表 17.3-1 に示します。

Table 17.3-1: Actors and Options
Actor

OptionsVol. & Section

Form Filler

Archive FormITI TF-2b: 3.36

Data Clarifications

ITI TF-2b: 3.37

XFormsITI TF-1: 17.3.2

Form Manager

XFormsITI TF-1: 17.3.2

Form Processor

XFormsITI TF-1: 17.3.2

17.3.1 Archive Form オプション
Archive Form オプションは、保存の目的で、Form Filler が、書式インスタンスデータを Form Archiverに登録できるようにします。
17.3.2 Clarifications オプション
Clarifications オプションは、Form Filler が Form Manager から Clarifications Form を取得し、以前に登録したデータを更新して、Form Receiver に登録できるようにします。
17.3.3 XForms オプション
XForms オプションは、Form Filler と Form Manager が XForm の書式で Form データを交換できる
ようにします。このオプションの制限については ITI TF-2b: 3.34.4.1 を見てください。
17.4 Retrieve Form 処理の流れ
この節では、Form がデータ収集用に取得され、部分的に完成、あるいは、完成した後で格納される際の、処理とデータの流れを記述します。Form が完成したか否かの基準はこのプロファイルのスコープ

19

626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646

外です。
五つの場合に区別できます。
Case 1: これは、既知の書式 ID (formID)を使用して書式を取得する、単純な場合です。
書式の識別子である書式 ID は、臨床治験に参加するときの様に、Form Filler が把握しています。書式
ID の値は書式索引の公表、あるいは、個人的な連絡によっても、通知することが可能です。書式 ID を取得する方法はこのプロファイルの範囲外ですが、Retrieve Form の前提です。
二つのアクタ設定が可能です：
 Form Manager と Form Receiver がグルーピングされ Form Source として機能します。図 17.4－1 参照。
 Form Processor が存在します。図 17.4‐1b 参照
Form Filler は Form Manager または Form Processor に Retrieve Form を送信します。
Form Manager または Form Processor は、要求された書式を返すか、書式が使用できない
旨のエラーを返します。書式が返されたとき、Form Filler は書式インスタンスデータを、
書式提出用トランザクションを使用して Form Receiver、または、Form Processor に登録します。Form Manager と Form Receiver はグルーピングされているので、両者の間に部分完成の書式の場合の様に通信があるかも知れませんが、これは内部通信ですので、IHE
トランザクションではありません。
Form Filler

Form source
Form Manager

Form Receiver

Retrieve Form [ITI-34]

Submit Form [ITI-35]

647
648
649

図 17.4-1: Case 1: Retrieve Form と Submit Form；Form Manager は Form Receiver とグルーピングされている

20

Form Filler
Form Processor
Retrieve Form [ITI-34]

Submit Form [ITI-35]

650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668

図 17.4‐1b: Case 1: Retrieve Form と Submit Form；Form Processor
Case 2: Form Receiver が独立（すなわち、Form Manager とグルーピングされていない）の場合を説明します。
この図では二つの Form Receiver があります: 1) Form Filler とグルーピングされた中間の Form
Receiver、2) 最終のグルーピングされていない Form Receiver です。
書式の識別子である書式 ID は Form Filler に把握されており、中間的に書式を保存することのできる
一つのシステム内に Form Filler と Form Receiver が実装されています。これとは別に、最終的に書式
データを保存する、別システム上の Form Receiver があります。
Form Filler は Form Manager に Retrieve Form を送ります。Form Manager は、要求された書式を返すか、書式が使用できない旨のエラーを返します。書式が返されたとき、Form Filler は部分的に完成した書式を中間の Form Receiver に送ります。この一部が完成した書式は、Form Manager にあてた
もう一つの Retrieve Form 要求で取得でき、最終的に完成された書式を、最終保存―国のデータレジス
トリの様な独立の Form Receiver―に登録できます。登録するための挙動は書式によって制御されます
ので、書式の選択する、もしくは新たに作成することにより、格納後の挙動を Retrieve Form トランザ
クションの処理の中で指定するのは、Form Manager です。

21

Form Filler

form source
Form Manager

Form ReceiverForm Receiver

Retrieve Form [ITI-34]

Submit Form [ITI-35]

Retrieve Form [ITI-34]

Submit Form [ITI-35]

669
670
671
672
673
674
675
676
677
678

図 17.4-2: Case 2: Retrieve Form と Submit Form；Form Manager は Form Receiver と別に構成されている
Case 3: この場合は、Form Filler が保存オプションを使用します。
Form Filler は Retrieve Form を、指定された Form Archiver に書式を保存する必要がある旨を示して、Form Manager に出します。Form Manager は、要求された書式を返すか、書式が使用できない旨のエ
ラーを返します。Form Manager は Form Filler の Retrieve Form に指定された Form Archiver にArchive Form のトランザクションを実行できる様に書式を構成します。書式が戻され次いで提出されるとき、書式インスタンスデータは Form Receiver と Form Archiver に提出されます。

22

Form Filler

Form Archiverform source
Form Manager Form Receiver

Retrieve Form [ITI-34]

Submit Form [ITI-35]

Archive Form [ITI-36]

679
680
681
682
683
684
685
686
687
688
689
690
691
692

図 17.4-3: Case 3: Retrieve Form, Submit Form, Archive Form
Caee 4: この例は、書式 ID が事前にわからない場合の問題を解決するため書式デザインを使う一方法を示します。
書式の識別子である、書式 ID（formID）が Form Filler にわかっていませんが、内容値（名前、値）の対の一セットがわかっています。これらの値を入力すべき内容書式は、書式 ID を持ちます。内容書
式の事例データで集められた情報を Form Manager が使用して、Form Filler に戻すべきデータ収集書
類を決めます。
Form Filler は、実際のデータ収集書式を Form Manager が決める補助となる情報を集める内容書式を請求できるだけの情報を持っています。Form Filler は内容書式の一事例を完成し、これを Form
Receiver に提出すると、新しい事例データあるいは、新しい書式を戻します。
form source

Form Filler
Use form to submit
Context Informationin order to select theData Capture form

Form Manager
Form Receiver
Retrieve Form [ITI-34]

Submit Form [ITI-35]
Multiplesubmitactions
may takeplace.

Submit Form [ITI-35]
Fill in and submit
the actual Data
Capture Form.

693
694

図 17.4-4: Case 4: Retrieve Form と Submit Form

23

695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714

Case 5: この例では、Form Filler は Clarifications オプションをサポートしています。
Form Filler は Form Manager に Retrieve Clarifications 要求を送ります。Form Receiver と FormManager との相互作用はこのプロファイルの範囲外です。Form Manager に Clarifications 情報を提供する解決法の一例は、Form Manager と Form Receiver を図 17.4-5 と 17.4-6 の様に、グルーピングすることです。Form Filler が送る要求には組織識別子が入っており、Form Manager は要求を発した組織に関連する Clarifications 書式のセットのみを返送することができます。Form Manager は必要な情報を含む書式を返して、要求を発した部所あるいは組織がデータを必要に応じて補遺する要求ができる
ようにします。この様な ClarificationsRetrieve Form は、Form Filler により定期的に行われねばなりません。要求の頻度は Form Manager・Form Receiver とで決められ、あるいは合意された期間により定められると思われます。
Form Manager は変更すべきデータを含む書式か、他の書式への参照一覧のいずれかを返します。後者の場合には、参照された個々の書式は Retrieve Form トランザクションで取得されます。いずれの場合
も、データは変更されたうえ、Submit Form トランザクションにより、Form Receiver に提出されます。提出されたデータは、適切な扱いのため、スポンサーのデータ管理マネージャによって評価されます。
このプロファイルではこれら二つの応答を区別せず、書式にかかれて返送された内容で、Form Fillerの使用者が、返送された書式を適切に処理できる様にします。
Form Filler

Form source
Form Manager Form Receiver

Retrieve Clarifications [ITI-37]

Submit Form [ITI-35]

715
716
717

図 17.4-5: Case 5: Clarifications オプションが使用可能な Form Filler

24Form Filler

Form source
Form Manager Form Receiver

Retrieve Clarifications [ITI-37]

Retrieve Form [ITI-34]
Can berepeated

Submit Form [ITI-35]

718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745

図 17.4-6: Case 5: Clarifications オプションが使用可能な Form Filler
17.5 安全性の考慮
17.5.1 RFD リスク分析とリスク評価
RFD のリスク分析には、資産、脅威と軽減策があります。リスクデータの完全な一覧は IHE に保存され、IHE から取得可能です2。
リスク評価の目的は、RFD アクタを実装する際、ベンダが考慮するよう助言されるリスクのいくつかを知らせることにあります。IHE の一般的なリスクと脅威については、ITI TF-1: 付録 L を参照してください。多くのリスクは IHE プロファイルでは解決できず、かわりに、軽減策の責任は、ベンダ、時に連携ドメイン、個々の施設や実装者に転嫁されることを、ベンダに助言します。この様な場合、IHE
は以下の節を使用してリスクを受けた団体に通知して、IHE の責任を果たします。
17.5.2 推奨
高リスクには、正確性の過誤、データと図式の間での相違、事業秘密の開示、があります。このプロフ
ァイルには軽減策があります。
M1. 使用者が間違った書式を取得した場合には、書式を破棄します。Retrive Form トランザクション
は状態が関係しないので、書式の破棄は何の問題も起こしません。
M2. XForm オプションを使用する場合、データモデルの図式証明は XForm モデルが提供します。
XForm プラグインは XForm の処理と表示の責任を負いますが、これはこの統合プロファイルの範囲外です。
M3. TLS の実装は可能で、プライバシ保護と施設使用者認証を要する連携ドメインや施設はこれを使用できます。
（実装者は TLS を実装せねばなりません。これを有効にする決定は連携ドメインと施設に任されます。
M4. 書式証明（form validations）は、値が欠損している書式の提出を防ぎます。
M5. 元データを信頼できる第三者のもとで保管する RFDArchive Form トランザクションは、施設で使用できます。
2

リスク分析データは ftp://ftp.ihe.net/IT_infrastructure/iheitiyr5-2007-2008/
Technical_Cmte/Profile_Work/RFD/RFD%20Risk%Analysis%202007-05-15.xls にあります。Analysis%202007-05-15.xls に
あります。

25

746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791

これらの軽減策（実行の責任）はベンダとその代理人に移されます。
T1. データの入力や提出の前に、書式提供者が提示された書式を評価し閲覧するよう、IHE は推奨します。提供者の閲覧で、データが正しい書式に記されているか、正しい患者のものかを確認しますが、これは書式回収と提出の核心的部分です。販売者は、RFD を医師が介在しない治療や診断に使用しないよう警告されています。患者のいかなる治療や診断のまえに必ず医師が介在して、送信中に起こりうる
エラーがヒトにより確認される様にせねばなりません。
T2 使用可能な書式のオプションにより、書式内で基本的有効性確認ができるようになっています。これを利用して、入力エラーなどから守るのは、書式開発者・実装者の責任です。
T3. 部分的に完成された書式が必要な場合は、データを提出する組織の業務フローに問題があることを示します。
T4. 書式や業務フローの設計者は可能であれば、書式を順次的な段階的な書式に分化せねばなりません。
T5. 書式のデザインは、業務フローとそのギャップの評価を容易にするものでなければなりません。
T6. クライアント側でのアクセスコントロールとセキュリティは、情報漏洩の可能性を軽減する重要な因子です。
T7. どのシステムが Form Filler を果たすかを決定する際には、基本方針による制御が推奨されます。
T8. どの使用者が書式に記述するかを決定する際には、基本方針による制御が推奨されます。
T9. このプロファイルは監査記録を必要としません。エラーを減少させ不正な使用を防ぐため、施設での監査記録システムが推奨されます。
T10. 書式に入力したデータを元に戻す機能がアプリケーションに必要なことがあります。
T11. データ説明の必要を通知します。
T13. Form Manager、Form Receiver、Form Archiver は保護されたシステムでなければなりません。
T14. ネットワーク、セットワーク基盤、およびシステムの強靱性の考慮が必要です。特に災害、流行、その他現地の基盤がかなり破壊された状況で使用される書式アプリケーションでは特に必要です。
T15. 災害、流行、その他現地の基盤がかなり破壊された状況で使用されるアプリケーションでは、長い遅延時間、狭い通信帯域での通信にあわせて書式はデザインされねばなりません。
T16. Form Filler は使用者のエラー、ネットワーク障害、ハードウエア障害に対して強靱でなければなりません。
T17. 要求事項を収集している時期には、業務フローを処理せねばなりません。ベンダは、クライアン
トと業務フローを議論するよう、助言されます。
T18. ベンダは記録と監査リポジトリの実装を考える様に助言されます。

B. Technical Framework Volume 2
3.34 Retrieve Form [ITI-34]（書式取得）
このセクションは、IHE IT 基盤テクニカルフレームワークのトランザクション ITI-34 に該当する。ト
ランザクション ITI-34 は Form Filler と Form Manager もしくは Form Processor アクタによって使用される。
3.34.1 範囲
このトランザクションには Form Filler による Form Manager もしくは Form Processor への書式の要求が含まれます。Form Filler はこのトランザクションの範囲外である手段によって得られた FormIDと追加のワークフロー情報を所持している。Form Filler は以前に提出した書式を参照する書式のインスタンス id（form instance id）を提供してもよい。Form Manager や Form Processor は指定された
FormID と任意の書式のインスタンス id に該当する書式もしくは URL を返すか、そうでなければエラー応答を返す。書式は書式オプションにより以下の定義と制約が定められている。

26

792

793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825

3.34.2 ユースケースロール

アクタ：Form Filler
役割：書式のフィールドに入力して完成させることが可能な能力を持つ書式表示および編集システム
アクタ：Form Manager
役割：特定の FormID と任意の追加ワークフローデータを提供する要求に基づき書式を提供するシステ
ム。書式データは Form Receiver に提出される。
アクタ：Form Processor
役割：特定の FormID と任意の追加ワークフローデータを提供する要求に基づき書式を提供するシステ
ム。このアクタからの書式データは自身に提出されなければならない。
3.34.3 参照規格
このトランザクションの実装者は ITI TF-2x: Appendix V: IHE トランザクションのための Web サービ
スに記載された全ての要求事項に適合しなければならない。
IETF RFC1738, Uniform Resource Locators (URL), December 1994,
http://www.faqs.org/rfcs/rfc1738.html
IETF RFC2616 HyperText Transfer Protocol HTTP/1.1
Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October
2000. http://www.w3.org/TR/REC-xml.
ITI TF-2x: Appendix V Web Services for IHE Transactions
XForms 1.1, W3C Working Draft. http://www.w3.org/TR/2004/WD-xForms11-20041115/
XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition). A ReFormulation ofHTML 4 in XML 1.0. W3C Recommendation 26 January 2000, revised 1 August 2002.
http://www.w3.org/TR/xhtml1.
XHTML™ Basic. W3C Recommendation 19 December 2000.
http://www.w3.org/TR/xhtml-basic.

27

826

827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857

3.34.4 相互作用図

3.34.4.1 Retrieve Form の要求
Retrieve Form には、Form Filler による Form Manager もしくは Form Processor への書式の要求が含まれます。Form Filler はワークフローデータと事前入力データを供給しなければならない。Form
Filler は書式のインスタンス id を提供してもよい。
Retrieve Form の要求はヌル値もしくは Form Archiver アクタを指す URL としての archiveURL の値が提供できなければならない。詳細についてはセクション 3.34.4.1.2 を参照のこと。
Form Filler の要求とは、
Form Filler もしくは Form Processor で使用される prepopData 引数と Form
Filler コンテキストを表す整形式 XML を供給することによって返される書式の選択およびもしくは生成のときのコンテキスト情報である。preopData スキーマの仕様は、コンテンツプロファイルに委ねられている。この値はヌル値でもよい。
Form Filler は wrokflowData パラメータのコンテキストエレメントを使用して書式の選択およびもしくは生成で利用される任意の追加ワークフロー情報を提供します。このコンテキストエレメントの仕様
はコンテンツプロファイルに委ねられている。
Retrieve Form の要求に対する応答は、書式もしくは書式への参照が返却され、書式のインスタンス id
を返しても良い。
3.34.4.1.1 トリガイベント
Form Filler は、人間による決定や自動動作のためのルールの適用に基づき、Form Manager あるいはForm Processor によって保持されている書式を要求します。
3.34.4.1.2 メッセージの内容
このトランザクションの実装者は ITI TF-2x: Appendix V: IHE トランザクションのための Web サービ
スに記載された全ての要求事項に適合しなければなりません。以下のパラメータはこのトランザクショ
ンのために規定されている。
パラメータ名

要求

説明

28

値

858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888

prepopData

R

事前入力書式フィールドに使用するために Form Filler によって供給された xml コンテキスト情報

この値はヌル値もしくは整形式 XML 文書でなくてはならな
いworkflowData

R

ワークフローで規定された XML 表
現の値

この値は以下に定義されたような整形式 XML 文書

formIDR

書式の識別子

書式の識別子の文字列

encodedResponseR

エンコードされた応答を返すようにするかどうかを Form Manager に指示する{true,false}archiveURL

R

Form Filler が Archive オプションを行使するかどうかを FormManager に指示する

任意の Form Filler が識別する
Form Archiver の URL もしくはヌル文字列contextR

ワークフローコンテキストの XML
規約

コンテンツプロファイルで定義される；おそらくヌル値

instanceID

R

以前に提出したデータのインスタ
ンスの id 値

以前に提出したデータのインスタンスを識別する文字列；おそらくヌル値

prepopData パラメータの内容は IHE コンテンツプロファイルによって規定される prepopData スキーマで定義されている。prepopData が無い場合、属性 xsi:nill は"tue"をセットしなければならない（サポート資料を参照すること）。
workflowData パラメータの内容は、最小限次の様でなければならない：<workflowData><formID>a String identifying the form</formID><encodedResponse>false</encodedResponse><archiveURL /><context/><instanceID/></workflowData>
サポート資料（ftp://ftp.ihe.net/TF_Implementation_Material/ITI/）で提供されているスキーマを参照
すること。workflowData は、<context>エレメントの追加定義のあるコンテンツプロファイルによって拡張されるかもしれない。
3.34.4.1.3 期待する動作
Retrieve Form の要求を受信すると、Form Manager あるいは Form Processor は要求を解析し、RetrieveFormResponse エレメント内に要求された応答もしくは SOAP フォルトを含むエラーを返信しなければならない。Form Manager は書式または以下の値に基づく URL を返信しなければならな
い：a) encodedRespsonse; b) fromID; c) 任意の workflowData; d) オプションで提供される instanceID。
encodedReponse が「true」の場合、Form Manager あるいは Form Processor からの応答は、構造化（XML）あるいは非構造化（non-XML）要素のどちらかでなくてはならない。encodedReponse が「true」の場合、断片化されていない識別子のすべてのアンカーアドレスは絶対 URI で構成されていなくてはならない。
encodedReponse が「false」の場合、Form Manager あるいは Form Processor からの応答は、書式の

29

889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916

検索および操作のためのウェブブラウザによる直接使用が可能な URL エレメントでなければならない。

917

表 3.34.4.1.3-1: SOAP フォルト

Form Manager あるいは Form Processor は書式インスタンス id（form instanceID）の値の割り当てと返信を行っても良い。
Form Filler が要求の archiveURL パラメータに有効な URL を提供したとき、Form Manager もしく
は Form Processor は、書式の提出に関連した任意の事前定義されたアクションに加えて、提出された書式に基づく Archive Form トランザクションを実施しなければならない。セクション 3.36 Archive
Form で示すように、この追加の保存トランザクションは Form Filler と Form Archiver アクタとの間で実施される。
Form Filler が prepopData パラメータでデータを提供するとき、Form Manager もしくは Form
Processor は返却される書式と書式の事前入力フィールドを決定するためにこの情報を使用しても良い。
prepopData の正確な使用法と構造は IHE コンテンツプロファイルの公開まで延期される。
Form Manager もしくは Form Processor は、返却される書式と書式の事前入力フィールドを決定する
ために workflowData パラメータ内の値と同じようにオプションで供給される instanceID を使用しなければならない。
FormID の値は、命名済書式オプションのひとつを使用して Form Filler に返却されるフォームの識別
子は Form Manager あるいは Form Processor によって予め割り付けられている。Form Manager ある
いは Form Processor は複数の命名済オプションに対応可能だが、それぞれの FormID のために対応する命名済オプションはただひとつとする
Form Manager あるいは Form Processor は、表 3.34.4.4.1.3-1 に定義された SOAP フォルトを適切に使用しなければならない。Form Filler はここに規定された値以外の他の値も受け入れる能力がなければならない。

エラー定義

918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933

コード

理由テキスト

情報が不足している。formID がない、など

SenderRequired Information Missing

フォームが利用できない

SenderUnknown formID

SOAP フォルトの例は次の通り：<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:xml="http://www.w3.org/XML/1998/namespace"><env:Body><env:Fault><env:Code><env:Value>env:Sender</env:Value></env:Code><env:Reason><env:Text xml:lang="en">Required Information Missing</env:Text></env:Reason></env:Fault></env:Body></env:Envelope>

30

934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950

3.34.4.1.4 セキュリティに関する注意事項
ITI TF-1: 17.5 安全性の考慮の推奨セクションでの記載の様に、エンドポイントは追加のプライバシと保護のために必要に応じて TLS を実装することは自由である。データの特性に基づいて、コンテンツ
プロファイルは ATNA の使用を要求するかもしれない。
3.34.4.2 Retrieve Form の応答
3.34.4.2.1 トリガイベント
このメッセージは Retrieve Form の要求に応答する Form Manager あるいは Form Processor アクタによって発生されます。
3.34.4.2.2 通信文の内容
書式もしくは URL が返還される。
以下のパラメータがこのトランザクションの応答のために規定される。
説明

制約

form

エレメント名称R

要求

書式のための XML エレメントコ
ンテナ。書式のエレメントは次のどれかを含まなくてはならない：{Structured, Unstructured, URL}
instanceID.を含んでも良い。

型のエレメント
urn:ihe:iti:rfd:2007:formDataType、このようにチャイルドエレ
メントだけを持ち、値はない。

form/Structured

O [Note 1]

エンコードされた返還のためのXML エレメントコンテナ、構造化
書式のコンテンツ。

xs:anyこのエレメントはコンテンツ
プロファイルによって更に制約されるかもしれない。
書式の要求が encodedResponseに「true」の値を持つ場合のみ存在してもよい。

form/Unstructured

O [Note 1]

エンコードされた返り値、非構造化、base64 でエンコードされた書式のコンテンツのための XML エ
レメントコンテナ。

xs:base64Binary
このエレメントはコンテンツ
プロファイルによって更に制約されるかもしれない。
書式の要求が encodedResponseに「true」の値を持つ場合のみ存在してもよい。

form/URL

O [Note 2]

書式のポインタの返還のためのXML エレメントコンテナ。

xs:anyURI書式の要求が encodedResponseに「false」の値を持つ場合は必須である。

form/instanceID

O

書式インスタンスの値を持つ
XML エレメント

xs:string31

エレメント名称
contentType

responseCode

要求
R

R

説明

制約

書式の要求の encodedResponse の値が「false」の場合、意味を持たない。

xs:string
必須：おそらくヌル。

定義なし

xs:string
必須：おそらくヌル。

この値はコンテンツプロファ
イルによって制約されるかもしれない。

この値はコンテンツプロファ
イルによって制約されるかも
しれない。

951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985

Note 1： 書式の要求が encodedResponse の値に「true」を持つ場合、二つのうちの一つのフィールドは必須であり、URL フィールドは禁止される。
Note 2： 書式の要求が encodedResponse の値に「false」を持つ場合、URL フィールドは必須であり、構造化および非構造化は禁止される。
3.34.4.2.3 期待する動作
Form Filler は、Retrieve Form トランザクションの encodedResponse 値が「false」の場合、返された
URL の値から書式を取得しなければならない。
Retrieve Form の encodedResponse 値にかかわらず、Form Filler は書式の提出のために必要な任意の書式のフィールドを全て入力が可能で、ユーザとの対話のためのフォームを表示しても良い。
3.34.4.2.3.1 XHMTL の取り扱い
Form Manager あるいは Form Processor は書式を返さなければなりません。要求の encodedResponse
値が「false」であるために書式が URL として返された場合は、書式は XHTML Basic と W3C XHTML
1.0 Recommendation の Appendix C で提供されている W3C HTML Compatibility Guideline を使用
する XHTML として書式化されなければならない。書式が構造化されたコンテンツとして返された場合、
XHTML に変換されることが可能でなければならない。すべての場合において、返される書式は提出とすべての要求された保存トランザクションに対応しなければならない。
3.34.4.2.3.2 XForm オプション
XForms オプションに対応している Form Manager あるいは Form Processor は、応答のような返信を返すもしくは URL を返すことによる参照のどちらであっても、XForms 1.1 に適合する書式を返す追加の能力がなければならない。XForms のホスト言語は、W3C XHTML 1.0 Recommendation の Appendix
C で提供されている W3C HTML Compatibility Guideline に従った XHTML Basic でなければならない。返される書式は提出とすべての要求された保存トランザクションに対応しなければならない。
3.34.5 プロトコルの必須事項
Retrieve Form の要求と応答は、ITI TF-2x: Appendix V で規定された必須事項に従って、同期 Web サービス交換を使用して伝達しなければならない。
Retrieve Form トランザクションは SOAP 1.2 を使用しなければならない。

32

986

987
988
989
990
991
992

WSDL Namespace 定義
iheurn:ihe:iti:rfd:2007

soap12

http://schemas.xmlsoap.org/wsdl/soap12/

wsaw

http://www.w3.org/2005/08/addressing

xsd

http://www.w3.org/2001/XMLSchema

これらは、WSDL 定義に出現する順序で提示される Retrieve Form トランザクションのための必須要件である：
以下の型は、/definitions/types セクションにインポート（xds:import）されなければならない。
Namespace="urn:ihe:iti:rfd:2007", schema="RFD.xsd"

993
994

 Retrieve Form 要求メッセージの/definitions/message/part/@element 属性は、"ihe:Retrieve
Form Request"として定義されなくてはならない。

995
996

 Retrieve Form 応答メッセージの/definitions/message/part/@element 属性は、"ihe:Retrieve
Form Response"として定義されなくてはならない。

997
998

 Retrieve Form 要求メッセージの/definitions/portType/operation/input/@wsaw:Action 属性は、
"urn:ihe:iti:2007:RetrieveForm"として定義されなくてはならない。

999
1000

 Retrieve Form 応答メッセージの/definitions/portType/operation/output/@wsaw:Action 属性
は、"urn:ihe:iti:2007:RetrieveFormResponse"として定義されなくてはならない。

1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023

 /definitions/binding/operation/SOAP12:operation/@SOAPAction 属性は、“false”として定義されなくてはならない。
これらは SOAP メッセージのワイヤーフォーマットに影響する必須事項です。その他の WSDL プロパ
ティは WSDL 定義内でのみ使用され、相互運用性には影響しない。要求と応答メッセージの完全なサ
ンプルはセクション 3.34.5.1 SOAP メッセージのサンプルにある。
Form Manager のための WSDL の参考情報と RFD のための完全な XML スキーマ文書の型は、IHEの FTP サイトからオンラインで入手可能である。ITI TF-2x: Appendix W を参照すること。
3.34.5.1 SOAP メッセージのサンプル
以下の二つのセクション内のサンプルは、典型的な SOAP 要求とそれに関連する SOAP 応答を示している。サンプルメッセージは WS-Addressing ヘッダの<Action/>, <MessageID>も示している；これらの WS-Addressing ヘッダは ITI TF-2x: Appendix X IHE トランザクションのための Web サービスに従って値がセットされている。SOAP メッセージの Body 部の一部は簡略化のため省略されている。
3.34.5.1.1 Retrieve Form SOAP 要求メッセージのサンプル<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID>

33

1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074

<wsa:Action
soap:mustUnderstand="1">urn:ihe:iti:
2007:RetrieveForm</wsa:Action></soap:Header><soap:Body><RetrieveFormRequest xmlns="urn:ihe:iti:rfd:2007"><prepopData>...some xml content...</prepopdata><workflowData><formID>1</formID><encodedResponse>false</encodedResponse><archiveURL /><context /><instanceID /></workflowData></RetrieveFormRequest></soap:Body></soap:Envelope>3.34.5.1.2 Retrieve Form SOAP 応答メッセージのサンプル<soap:Envelope

xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID><wsa:Action
soap:mustUnderstand="1">urn:ihe:iti:
2007:RetrieveFormResponse</wsa:Action></soap:Header><soap:Body><RetrieveFormResponse xmlns="urn:ihe:iti:rfd:2007"><form><URL>http://somehost/xxx/services/someForm</URL><instanceID>1.2.3.4.5</instanceID></form><contentType /><responseCode /></RetrieveFormResponse></soap:Body></soap:Envelope>3.35 Submit Form [ITI-35]
このセクションは、IHE IT 基盤テクニカルフレームワークのトランザクション ITI-35 に該当する。ト
ランザクション ITI-35 は Form Filler と Form Receiver もしくは Form Processor アクタによって使用される。
3.35.1 範囲
このトランザクションは、Form Filler の Form Manager あるいは Form Processor への書式の転送を含んでいる。

34

1075

3.35.2 ユースケースロール
Form Filler

Form ReceiverForm Processor

Submit Form

1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101

アクタ：Form Filler
役割： 書式のフィールドへの入力完成を可能とする能力を持つ書式表示および編集システム
アクタ：Form Receiver
役割： Form Manager によって構成された書式から提出された書式のデータを受け取るシステム。
アクタ：Form Processor
役割： Form Processor のこの同じインスタンスによって構成された書式から提出された書式データを受け取るシステム。
3.35.3 参照規格
このトランザクションの実装者は ITI TF-2x: Appendix V: IHE トランザクションのための Web サービ
スに記載された全ての要求事項に適合しなければならない。
IETF RFC1738, Uniform Resource Locators (URL), December 1994,
http://www.faqs.org/rfcs/rfc1738.html
IETF RFC2616 HyperText Transfer Protocol HTTP/1.1
Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October
2000. http://www.w3.org/TR/REC-xml.
ITI TF-2x: Appendix V Web Services for IHE Transactions
3.35.4 相互作用図
Form Receiver orForm Processor

Form Filler

Submit Form [ITI-35]

Ack/Nak response

1102
1103
1104

3.35.4.1 Submit Form
このトランザクションは Form Filler が書式のインスタンスデータを、XML フォーマットを使用して

35

1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125

Form Receiver または Form Processor に送信するときに開始される。
3.35.4.1.1 トリガイベント
Submit Form トランザクションは書式内からの書式提出動作によって発行される。
3.35.4.1.2 メッセージの内容
Submit Form トランザクションは、SubmitFormRequest エレメントの XML チャイルドエレメントとして提出された書式データと共に SubmitFormRequest エレメントを送らなければならない。コンテン
ツプロファイルは更に SubmitFormRequest エレメントの内容を制限するかもしれない。
サポートで提要しているスキーマを参照すること（ITI TF-2x: Appendix W を参照）。
3.35.4.1.3 期待する動作
Submit Form 要求を受信すると、Form Receiver または Form Processor は SubmitFormResponse エ
レメントもしくは、SOAP フォルトを含むエラー（例えば提出されたデータが認識できないとき）を返信しなければならない。
Form Filler は、Form Receiver または Form Processor からの応答結果を表示してもよい。
Form Receiver または Form Processor は、適切なときに表 3.35.4.1.3-1 に定義された SOAP フォルトを使用しなければならない。

1126

表 3.35.4.1.3-1: SOAP フォルト
エラーの説明コード提出されたデータが認識できない

1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150

Sender

理由テキストRequired Information Missing

SOAP Faults の例は以下の通り：<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope"
xmlns:xml="http://www.w3.org/XML/1998/namespace"><env:Body><env:Fault><env:Code><env:Value>env:Sender</env:Value></env:Code><env:Reason><env:Text xml:lang="en">Required InFormation Missing</env:Text></env:Reason></env:Fault></env:Body></env:Envelope>
3.35.4.2 Submit Form の応答
3.35.4.2.1 トリガイベント
このメッセージはForm Fillerの書式のインスタンスデータの提出によって発行される。
3.35.4.2.2 メッセージの内容
Submit Form 応答は以下を含む SubmitFormResponseType エレメント返信しなければならない：

36

1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168

1169
1170
1171
1172
1173

コンテンツプロファイルで制限されるかもしれない responseCode 文字列
RetrieveFormReponse によって返信されるような FormData を含むオプションのコンテ
ンツエレメント コンテンツプロファイルによって制限されるかもしれないオプションの contentType 文字
列
サポート資料で提供されているスキーマを参照すること（ITI TF-2x: Appendix W を参照）

3.35.4.2.3 期待する動作
Form Filler は Form Receiver または Form Processor からの応答結果を表示してもよい。書式の動作
はコンテンツプロファイルによって更に制限されるかもしれない。
3.35.5 プロトコルの必須事項
このトランザクションの実装者は ITI TF-2x： Appendix V： IHE トランザクションのためのウェブサ
ービスに記載されているすべての必須事項に適合しなければならない。
Submit Form トランザクションは SOAP 1.2 を使用しなければならない。

WSDL Namespace Definitions
ihe

urn:ihe:iti:rfd:2007

soap12

http://schemas.xmlsoap.org/wsdl/soap12/

wsaw

http://www.w3.org/2005/08/addressing

xsd

http://www.w3.org/2001/XMLSchema

これらは、RFD Submit Form WSDL 定義に出現する順番で示す Submit Form トランザクションのための必須事項である。
1174

以下の型が/definitions/types セクションにインポート（xds:import）されなければな
らに。
 Namespace="urn:ihe:iti:rfd:2007", schema="RFD.xsd"

1175
1176



Submit Form 要 求 メ ッ セ ー ジ の /definitions/message/part/@element 属 性 は 、"ihe:SubmitFormRequest"として定義されなければならない。

1177
1178



Submit Form 応 答 メ ッ セ ー ジ の /definitions/message/part/@element 属 性 は 、"ihe:SubmitFormResponse"として定義されなければならない。

1179
1180
1181
1182
1183
1184
1185
1186
1187



追加する属性の必須事項については、表 3.35.5-1 を参照すること。

37

1188

表 3.35.5-1: 追加属性必須事項
属性

1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229

値

/definitions/portType/operation@nameSubmitForm/definitions/portType/operation/input/@wsaw:Actionurn:ihe:iti:2007:SubmitForm/definitions/portType/operation/output/@wsa
w:Action

urn:ihe:iti:2007:SubmitFormResponse/definitions/binding/operation/wsoap12:opera
tion/@soapActionRequired

false

これらは SOAP メッセージのワイヤーフォーマットに影響する必須事項である。その他の WSDL プロ
パティは WSDL 定義内でのみ使用され、相互運用性には影響しない。要求と応答メッセージの完全なサンプルはセクション 3.35.5.1 SOAP メッセージのサンプルにある。
WSDL の参考情報は、ITI TF-2x: Appendix W を参照すること。
<ihe:SubmitFormRequest>エレメントは、次のように定義される：
ひとつ以上の <xs:any> エレメント
これにより、Form Manager はどのような XML 表現を使用する提出書式データでも書式として構成することができる。
<ihe:SubmitFormResponse>エレメントは、次のように定義される：






Retrieve Form の 応 答 で も 使 用 さ れ る <ihe:formDataType> 型 の オ プ シ ョ ン で あ る<ihe:cintent>エレメント。もし存在するのであれば以下を含まなければならない：
以下の中からひとつ：
 書式の XML エンコーディングを含んだ<ihe:Structured> 書式の base64 バイナリエンコーディングを含んだ<ihe:Unstructured> 書式の URL を含んだ<ihe:URL> xs:string 型のオプションである<ihe:instanceID>
xs:string 型のオプションである<ihe:contentType>xs:string 型の必須である<ihe:responseCode>3.35.5.1 SOAP メッセージのサンプル
以下の２つのセクションに典型的な SOAP 要求とそれに関連する SOAP 応答を示す。サンプルメッセ
ージは WS-Addressing ヘッダの<Action/>, <MessageID>も示している；これらの WS-Addressing ヘ
ッダは ITI TF-2x: Appendix X IHE トランザクションのためのウェブサービスに従って値がセットされている。SOAP メッセージの Body 部の一部は簡略化のため省略されている。
3.35.5.1.1 Submit Form SOAP 要求メッセージのサンプル<?xml version='1.0' encoding='UTF-8'?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID><wsa:Action soap:mustUnderstand="1">urn:ihe:iti: 2007:SubmitForm</wsa:Action></soap:Header><soap:Body>

38

1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273

<SubmitFormRequest xmlns="urn:ihe:iti:rfd:2007">…
</SubmitFormRequest></soap:Body></soap:Envelope>

3.35.5.1.2Submit FormSOAP 応答メッセージのサンプル<?xml version='1.0' encoding='UTF-8'?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID><wsa:Action soap:mustUnderstand="1">urn:ihe:iti:
2007:SubmitFormResponse</wsa:Action></soap:Header><soap:Body><SubmitFormResponseType xmlns="urn:ihe:iti:rfd:2007"><content><URL>http://somehost/xxx/services/someForm</URL><instanceID>1.2.3.4.5</instanceID></content><contentType /><responseCode /></SubmitFormResponseType></soap:Body></soap:Envelope>

3.35.6 セキュリティに関する注意事項
ITI TF-1: 17.5 安全性の考慮の推奨セクションでの記載の様に、エンドポイントは追加のプライバシと保護のために必要に応じて TLS を実装することは自由である。データの特性に基づいて、コンテンツ
プロファイルは ATNA の使用を要求するかもしれない。
3.36 Archive Form [ITI-36]
このセクションは、IHE IT 基盤テクニカルフレームワークのトランザクション ITI-36 に該当する。ト
ランザクション ITI-36 は Form Filler と Form Archiver アクタによって使用される。
3.36.1 範囲
このトランザクションは、Form Archiver に Form Filler が書式インスタンスを提出することを含んでいる。
3.36.2 ユースケースロール
Form Filler

Form ArchiverArchive Form

1274
1275
1276
1277

アクタ：Form Filler
役割： 書式のフィールドへの入力完成を可能とする能力を持つ書式表示および編集システム
アクタ：Form Archiver

39

1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291

1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314

役割： 保存目的のために提出書式を受信するシステム。
3.36.3 参照規格
このトランザクションの実装者は ITI TF2x: Appendix V: IHE トランザクションのためのウェブサービ
スに記載された全ての必須事項に適合しなければならない。
IETF RFC1738, Uniform Resource Locators (URL), December 1994,
http://www.faqs.org/rfcs/rfc1738.html
IETF RFC2616 HyperText Transfer Protocol HTTP/1.1
Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October
2000. http://www.w3.org/TR/REC-xml.
ITI TF-2x: Appendix V Web Services for IHE Transactions
3.36.4 相互作用図

3.36.4.1 Archive Form
このトランザクションは、保管目的のために Form Filler が Form Archiver へデータを提出することにより開始される。
3.36.4.1 .1 トリガイベント
Form Filler は、保管目的で Form Archiver にデータを提出するためにこのトランザクションを使用しなければならない。Archive Form トランザクションは Form Filler によって開始されてもよいし、書式内にある二次的提出動作から発生させてもよい。
3.36.4.1.2 メッセージの内容
Archive Form トランザクションは、ArchiveFormRequest エレメントと ArchiveFormRequest エレメ
ントの XML チャイルドエレメントとして提出された書式データを送信しなければならない。
サポート資料で提示するスキーマを参照すること（ITI TF-2x: Appendix W を参照）。
3.36.4.1.3 期待する動作
Archive Form 要求を受信すると、Form Archiver は ArchiveFormResponse エレメントもしくは、例
えば送信されたデータが認識できない場合には SOAP フォルトを含むエラーを返信しなければならな
い。
Form Filler は、Form Receiver からの応答結果を表示してもよい。

40

1315
1316
1317

Form Archiver は、表 3.36.4.1.3-1 で定義された SOAP フォルトを適切なときに使用しなければならな
い。Form Filler はここに規定した以外の他の値を受け入れる能力がなければならない。

1318

表 3.36.4.1.3-1: SOAP フォルト
エラーの説明コード送信されたデータが認識できなかった

1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355

Sender

理由テキストRequired Information Missing

SOAP フォルトの例は以下のとおり：<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope"
xmlns:xml="http://www.w3.org/XML/1998/namespace"><env:Body><env:Fault><env:Code><env:Value>env:Sender</env:Value></env:Code><env:Reason><env:Text xml:lang="en">Required Information Missing</env:Text></env:Reason></env:Fault></env:Body></env:Envelope>
3.36.4.2 Archive Form の応答
3.36.4.2.1 トリガイベント
このメッセージは Form Filler が書式インスタンスデータを保管することにより発生される。
3.36.4.2.2 メッセージの内容
ArchiveFormResponse エレメントは、以下を含んで返信される。


コンテンツプロファイルによって制限されるかもしれない responseCode 文字列

サポート資料で提示されているスキーマを参照すること（ITI TF-2x: Appendix W を参照）
3.36.4.2.3 期待する動作
Form Filler は Form Archiver からの応答結果を表示してもよい。書式の動作は、コンテンツプロファ
イルによってさらに分析されるかもしれない。
3.36.5 プロトコルの必須事項
Archive Form 要求と応答は、ITI TF-2x: Appendix V で規定されている要求事項に従い同期ウェブサー
ビス交換を使用して転送されなければならない。
Archive Form トランザクションは SOAP 1.2 を使用しなければならない。

1356

WSDL Namespace 定義
iheurn:ihe:iti:rfd:2007

soap12

http://schemas.xmlsoap.org/wsdl/soap12/

41

1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369

wsaw

http://www.w3.org/2005/08/addressing

xsd

http://www.w3.org/2001/XMLSchema

これらは、Archive Form WSDL 定義に出現する順番で提示された Archive Form トランザクションのための必須事項です。
 以下の型が/definitions/types セクションにインポート（xds:import）されなければならない。
 Namespace="urn:ihe:iti:rfd:2007", schema="RFD.xsd"
 Archive Form 要 求 メ ッ セ ー ジ の /definitions/message/part/@element 属 性 は"ihe:ArchiveFormRequest"として定義されなければならない。
 Archive Form 応 答 メ ッ セ ー ジ 文 の /definitions/message/part/@element 属 性 は"ihe:ArchiveFormResponse"として定義されなければならない。
 追加の属性要求事項のために表 3.36.5 を参照すること。

1370

表 3.36.5: 追加属性の要求事項
属性

1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391

値

/definitions/portType/operation@nameArchiveForm/definitions/portType/operation/input/@wsaw:Actionurn:ihe:iti:2007:ArchiveForm/definitions/portType/operation/output/@wsa
w:Action

urn:ihe:iti:2007:ArchiveFormR
esponse/definitions/binding/operation/wsoap12:opera
tion/@soapActionRequired

false

これらは SOAP メッセージのワイヤーフォーマットに影響する要求事項である。その他の WSDL プロ
パティは WSDL 定義内でのみ使用され、相互運用性には影響しない。要求と応答メッセージの完全なサンプルは 3.36.5.1 節 SOAP メッセージのサンプルにある。
WSDL の参考提供については ITI TF-2x: Appendix W を参照すること。
<ihe:ArchiveDrrmRequest>エレメントは、以下の様に定義される：


ひとつ以上の<xs:any>エレメント

これは Form Manager が、どのような XML 表現を使用した保存書式データの書式も構成することができる。
<ihe: ArchiveFormResponse >エレメントは、以下の様に定義される：


xs:string 型の<ihe:responseCode>エレメントは必須である

3.36.5.1 SOAP メッセージのサンプル
以下の２つのセクションのサンプルは典型的な SOAP 要求とそれに関連する SOAP 応答を示す。サンプルメッセージは WS-Addressing ヘッダの<Action/>, <MessageID>についても示す。これらのWS-Addressing ヘッダは ITI TF-2x: Appendix V IHE トランザクションのためのウェブサービスに従

42

1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446

って値がセットされている。SOAP メッセージの Body 部の一部は簡略化のため省略されている。
3.36.5.1.1 Archive Form SOAP 要求メッセージのサンプル<?xml version='1.0' encoding='UTF-8'?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID><wsa:Action soap:mustUnderstand="1">urn:ihe:iti: 2007:ArchiveForm</wsa:Action></soap:Header><soap:Body><ArchiveFormRequest xmlns="urn:ihe:iti:rfd:2007">…
</ArchiveFormRequest></soap:Body></soap:Envelope>

3.36.5.1.2 Archive FormSOAP 応答メッセージのサンプル<?xml version='1.0' encoding='UTF-8'?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID><wsa:Action soap:mustUnderstand="1">urn:ihe:iti:
2007:ArchiveFormResponse</wsa:Action></soap:Header><soap:Body><ArchiveResponse xmlns="urn:ihe:iti:rfd:2007"><responseCode /></ArchiveFormResponse></soap:Body></soap:Envelope>

3.36.6 セキュリティに関する注意事項
ITI TF-1: 17.5 安全性の考慮の推奨セクションでの記載の様に、エンドポイントは追加のプライバシと保護のために必要に応じて TLS を実装することは自由である。データの特性に基づいて、コンテンツ
プロファイルは ATNA の使用を要求するかもしれない。
3.37 Retrieve Clarifications [ITI-37]
このセクションは IHE ITI テクニカルフレームワークのトランザクション ITI-37 に該当する。トランザクション ITI-37 は Form Filler および Form Manager もしくは Form Processor によって使用される。
3.37.1 範囲
このトランザクションには、Form Filler が要求する Form Manager あるいは Form Processor からの説明のセットが含まれる。Retrieve Clarifications オプションに対応する Form Filler は、この要求をForm Manager、Form Receiver もしくは Form Processor で合意された定義に基づいて定期的に実施しなければならない。
すべてのユースケースがこのオプションの対応を必要としているわけではないことに注意すること。
Form Filler はこのトランザクション範囲外の手段により得た orgID を所有し、Form Manager あるい

43

1447
1448
1449
1450
1451
1452
1453
1454

は Form Processor は説明のためのデータもしくは Retrieve Form トランザクションを使用して取得することができた他の書式へのリンクのセットが含まれる書式を返すかのどちらかを行うことになる。

すべてのデータの更新／説明／作成は、Submit Form トランザクションを使用して Form Receiver に送信される。
3.37.2 ユースケースロール
Form Filler

1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477

Form Manager

Form Processor

Retrieve
Clarifications

アクタ：Form Filler
役割：書式のフィールドへの入力完成を可能とする能力を持つ書式表示および編集システム
アクタ：Form Manager
役割：特定の orgID を提供する要求に基づく説明情報を提供するシステム
アクタ：Form Processor
役割：特定の orgID を提供する要求に基づく説明情報を提供するシステム
3.37.3 参照規格
IETF RFC1738, Uniform Resource Locators (URL), December 1994,
http://www.faqs.org/rfcs/rfc1738.html
IETF RFC2616 HyperText Transfer Protocol HTTP/1.1
Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October
2000. http://www.w3.org/TR/REC-xml.
ITI TF-2x: Appendix V Web Services for IHE Transactions
XForms 1.1, W3C Working Draft. http://www.w3.org/TR/2004/WD-xforms11-20041115/
3.37.4 相互作用図44

Form Manager orForm Processor

Form Filler

Retrieve Clarifications Request

Retrieve Clarifications
Response

1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496

3.37.4.1 Retrieve Clarifications の要求
Retrieve Clarifications オプションに対応している Form Filler が組織またはサイトに関連する説明情報を取得する必要があるときはいつでもこのトランザクションが開始される。
3.37.4.1.1 トリガイベント
Retrieve Clarifications イベントは、現在の説明に関する情報のための必要性が生じたときに EHR シ
ステム内で利用できるようにする。トランザクションは、Retrieve Clarifications が発生するときを規定しているわけではなく、情報に関する説明を Form Manager または Form Processor から入手する必要があるときだけ、このトランザクションが利用可能になる。定期的にこのトランザクションを実行することはこのオプションに対応している Form Filler の責任である。
3.37.4.1.2 メッセージの内容
このトランザクションの実装者は、ITI TF-2x: APpendix V: IHE トランザクションのためのウェブサー
ビスに記載されているすべての必須要件に適合しなければならない。
以下のパラメータはこのトランザクションのために規定されている。
パラメータ名称

1497
1498

要求

説明
説明特有の値の XML 表現

値
以下に定義されるように、この値は整形式 XML 文書である

clarificationData

R

orgID

R

encodedResponseR

エンコードされた応答をかえすようにするかどうかを FormManager に指示する{true,false}archiveURL

R

Form Filler が Archive オプシ
ョンを行使するかどうかをForm Manager に指示する

任意の Form Filler が認識している Form Archiver のURL；おそらくヌル

contextR

ワークフローコンテキストのXML 規約コンテンツプロファイルによって定義される；おそらく
ヌル

組織の文字列による識別子

clarificationData は、IHE コンテンツプロファイルの<content>エレメントのさらなる定義により拡張

45

1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530

されるかもしれない。clarificationData 内容は最小限でなければならない：<clarificationData><orgID>a String identifying the form</orgID><encodedResponse>false</encodedResponse><archiveURL /><context/></clarificationData>
3.37.4.1.3 期待する動作
Retrieve Clarifications の要求を受信すると、Form Manager あるいは Form Processor は要求を解析しなければならない、そして RetrieveClarificationResponse エレメント内に要求された応答もしくはSOAP フォルトを含んだエラーを返信しなければならない。
Form Manager あるいは Form Processor は書式あるいは、次に示すような URL を返信しなければならない： a) encodedResponse; b) orgID; c) 任意の追加 clarificationData
説明情報が利用できない場合、説明情報がないことを表す書式による表記をしなければならない。
encodedResponse が「true」の場合、Form Manager あるいは Form Processor からの応答は、構造化（XML）あるいは非構造化（non-XML）エレメントのどちらかでなければならない。encodedResponse
パラメータが「true」の場合、すべてのアンカーアドレスは断片化されていない識別子で、絶対 URIで構成されていなくてはならない。
encodedResponse が「false」の場合、Form Manager あるいは Form Processor からの応答は、書式の取得と操作のためにウェブブラウザによる直接的な使用が可能な URL エレメントでなければならない。
orgID の値は以前に Form Manager あるいは Form Processor によって割り当てられていて、識別子は命名フォーマットオプションのひとつが使用される。Form Manager は複数の命名オプションに対応してもよいが、それぞれの orgID は対応している命名オプションのひとつだけとする。
Form Manager は、表 3.37.4.1.3-1 に定義される SOAP フォルトを適切なときに使用しなければならない。Form Filler はここに規定するもの以外の他の値を受け付ける能力がなければならない。

1531

1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543

表 3.37.4.1.3-1: SOAP フォルト
エラーの説明コード

情報が見つからない、orgID がないなど書式が存在しない

SenderSender

理由テキストRequired Information Missing
Unknown orgID

SOAP フォルトのサンプル：<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:xml="http://www.w3.org/XML/1998/namespace"><env:Body><env:Fault><env:Code><env:Value>env:Sender</env:Value></env:Code><env:Reason><env:Text xml:lang="en">Unknown orgID</env:Text>

46

1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587

</env:Reason></env:Fault></env:Body></env:Envelope>orgID は、命名フォーマットオプションのひとつを使用して Form Manager あるいは Form Processor
によって割り当てられる。Form Manager あるいは Form Processor は複数の命名オプションに対応してもよいが、それぞれの orgID は対応している命名オプションのひとつだけとする。
3.37.4.1.4 セキュリティに関する注意事項
Retrieve Clarifications 要求メッセージのためのセキュリティに関する注意事項は、Retrieve Form 要
求メッセージの定義と変更はない： セクション 3.34.4.1.4 を参照のこと。
3.37.4.2 Retrieve Clarifications の応答
3.37.4.2.1 トリガイベント
Retrieve Clarifications トランザクションで提供された orgID に基づく書式を提供する Form Manager
あるいは Form Processor により書式の伝達が発行される。
3.37.4.2.2 メッセージの内容
書式あるいは URL は、Retrieve Clarifications の応答で返信される。
3.37.4.2.3 期待する動作
Form Filler は、書式を表示するもしくは、書式を取得するために返された URL へ導いてもよい。
3.37.4.2.3.1 HTML の取扱い
Form Manager もしくは Form Processor は、応答として返されるもしくは URL で返されることによる参照のどちらであるにせよ XHTML Basic および W3C XHTML 1.0 Recommendation の Appendix C
で提供されている W3C HTML Compatibility Guidelines を使用する XHML フォーマットの書式を返信しなければならない。
3.37.4.2.3.2 XForm オプション
XForm オプションに対応している Form Manager あるいは Form Processor は、応答を返すもしくはURL を返す事による参照のどちらであるにせよ XForm 1.1 に適合する書式を返信する追加能力がなければならない。XForm のホスト言語は W3C XHTML 1.0 Recommendation の Appendix C で提供されている W3C HTML Compatibility Guidelines に従った XHTML Basic でなければならない。返信される書式は提出と保存トランザクションのすべての必須事項に対応しなければならない。

3.37.5 プロトコルの必須事項
Retrieve Clarifications の要求と応答は、ITI TF-2x: Appendix V で規定された要求事項に従って、同期
Web サービス交換を用いて伝達されなければならない。
Retrieve Clarifications トランザクションは SOAP 1.2 を使用しなければならない。

1588

WSDL Namespace 定義
iheurn:ihe:iti:rfd:2007

soap12

http://schemas.xmlsoap.org/wsdl/soap12/

47

1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636

wsaw

http://www.w3.org/2005/08/addressing

xsd

http://www.w3.org/2001/XMLSchema

これらは、WSDL 定義に出現する順番で提示する Retrieve Clarifications トランザクションのための必須事項である。
 以下の型が/definitions/types セクションにインポート（xds:import）されなければならない。
 Namespace="urn:ihe:iti:rfd:2007", schema="RFD.xsd"
 Retrieve Clarifications 要求メッセージの/definitions/message/part/@element 属性
は、"ihe:RetrieveClarificationRequest"として定義されなければならない。
 Retrieve Clarifications 応答メッセージの/definitions/message/part/@element 属性
は、"ihe:RetrieveClarificationResponse"として定義されなければならない。
 Retrieve Clarifications 要求メッセージの/definitions/portType/operation/input/@wsaw:Action 属性は、
"urn:ihe:iti:2007:RetrieveClarification"として定義されなければならない。
 Retrieve Clarifications 応答メッセージの/definitions/portType/operation/output/@wsaw:Action 属性は、
"urn:ihe:iti:2007:RetrieveClarificationResponse"として定義されなければならない。
 /definitions/binding/operation/soap12:operation/@soapActionRequired 属 性 は「false」として定義されなければならない。
これらは SOAP メッセージのためのワイヤーフォーマットに影響する要求事項です。その他の WSDL
プロパティは WSDL 定義内でのみ使用され、相互運用性には影響しない。要求と応答の完全なサンプ
ルはセクション 3.34.5.1 SOAP メッセージのサンプルにある。
Form Manager のための WSDL の参考情報と RFD の型のためのすべての XML スキーマ文書は IHE
FTP サイト上でオンラインから入手できる。ITI TF-2x: Appendix W を参照すること。
3.37.5.1 SOAP メッセージのサンプル
次の２つのセクションは、典型的な SOAP 要求とそれに関連する SOAP 応答を示している。サンプル
メ ッ セ ー ジ は WS-Addressing ヘ ッ ダ の <Action/>, <MessageID> も 提 示 し て い る ； こ れ ら のWS-Addressing ヘッダは ITI TF-2x: Appendix V IHE トランザクションのためのウェブサービスに従って値がセットされている。
3.37.5.1.1 Retrieve Clarifications SOAP要求メッセージのサンプル<?xml version="1.0" encoding="utf-8"?><soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID><wsa:Action
soap:mustUnderstand="1">urn:ihe:iti:
2007:RetrieveClarifications</wsa:Action></soap:Header><soap:Body><RetrieveClarificationsRequest xmlns="urn:ihe:iti:rfd:2007"><clarificationData><orgID>123</formID>

48

1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671

<encodedResponse>false</encodedResponse><archiveURL /><context /></clarificationData></RetrieveClarificationsRequest></soap:Body></soap:Envelope>

3.37.5.1.2 Retrieve Clarifications SOAP 応答メッセージのサンプル<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID><wsa:Action
soap:mustUnderstand="1">urn:ihe:iti:
2007:RetrieveClarificationsResponse</wsa:Action></soap:Header><soap:Body><RetrieveClarificationsResponse xmlns="urn:ihe:iti:rfd:2007"><form><URL>http://somehost/xxx/services/someForm</URL></form><contentType /><responseCode /></RetrieveClarificationsResponse></soap:Body></soap:Envelope>49