IHE-JA-G0002 V2.33

・Integrating the Health Care Enterprise

データ入力用書式取得・提出に関する仕様（Retrieve Form for Data Capture
Integration Profile：RFD）

文書番号：IHE-J-A-G0002V2.33
版番号：2.33

2018年12月31日
一般社団法人日本IHE協会

Copyright © 2018: IHE International, Inc. 日本 IHE 協会© 2018

目次
1 はじめに................................................................................................................................................................... 5
2. 規格の適用範囲 ...................................................................................................................................................... 52.1 製品への実装 ............................................................................................................................................................ 5
2.2 著作権許諾 .............................................................................................................................................................. 6
3 用語と定義 ............................................................................................................................................................... 6
3.1 用語 .......................................................................................................................................................................... 6
4. 略語 ....................................................................................................................................................................... 7
5. 要求事項 ................................................................................................................................................................ 8
6 データ入力用書式取得・提出に関する仕様（RETRIEVE FORM FOR DATA CAPTURE INTEGRATION PROFILE,
RFD）の概要................................................................................................................................................................ 8
6.1 使用例 ...................................................................................................................................................................... 9
6.1.1 探索的新薬治験の使用例 ................................................................................................................................... 9
6.1.1.1 現状 ........................................................................................................................................................................... 10
6.1.1.2 望ましい状態............................................................................................................................................................... 10

6.1.2 公衆衛生報告使用例 ........................................................................................................................................ 11
6.1.2.1 公衆衛生シナリオ .........................................................................................................................................................11

6.1.3 薬物副作用報告・監視シナリオ .......................................................................................................................... 11
6.1.3.1 現状 ............................................................................................................................................................................11
6.1.3.2 望ましい状況................................................................................................................................................................11

6.1.4 我が国での薬剤副作用調査例 .......................................................................................................................... 126.2 データのネットワーク提出に制限のある場合 ............................................................................................................. 12
7. RFD の機能概要 .................................................................................................................................................... 12
7.1 アクタ・トランザクションの相互作用 ............................................................................................................................ 12
7.2 アクタ....................................................................................................................................................................... 13
7.2.1 書式管理役（Form Manager） ............................................................................................................................ 13
7.2.2 書式記入役 (Form Filler) ................................................................................................................................ 14
7.2.3 書式受領役 (Form Receiver) ............................................................................................................................ 14
7.2.4 書式保管庫 (Form Archiver) ............................................................................................................................. 14
7.2.5 書式処理役 (Form Processor) ......................................................................................................................... 14
7.3 トランザクション ........................................................................................................................................................ 14
7.3.1 書式取得（Retrieve Form） ................................................................................................................................. 14
7.3.2 書式提出（Submit Form） ................................................................................................................................... 14
7.3.3 書式保管（Archive Form） .................................................................................................................................. 14
7.3.4 明確化情報取得 （Retrieve Clarifications） ........................................................................................................ 14
7.4 データ取得書式取得・提出のオプション.................................................................................................................... 15
7.4.1 書式保存オプション （Archive Form） ................................................................................................................ 15
7.4.2 デ－タ明確化オプション（Data Clarifications Option） ......................................................................................... 15
7.4.3 XForms オプション ............................................................................................................................................. 15
7.5 RFD の処理流れ ...................................................................................................................................................... 15
7.6 安全の考慮 ............................................................................................................................................................. 20
7.6.1 RFD リスク分析とリスク評価................................................................................................................................. 21
7.6.2 安全考慮の概説 ............................................................................................................................................... 21
7.6.3 推奨 ................................................................................................................................................................. 21

Copyright © 2018: IHE International, Inc. 日本 IHE 協会© 2018

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

8 RFD のトランザクションの詳細 ................................................................................................................................... 23
8.34 書式取得[ITI-34] ................................................................................................................................................... 23
8.34.1 範囲 ............................................................................................................................................................... 23
8.34.2 使用例役割 .................................................................................................................................................... 23
8.34.3 参照規格 ........................................................................................................................................................ 23
8.34.4 相互作用図 .................................................................................................................................................... 24
8.34.4.1 書式取得請求 ........................................................................................................................................................... 24
8.34.4.2 書式取得応答 ........................................................................................................................................................... 27

8.34.5 プロトコル要求事項 ......................................................................................................................................... 29
8.34.5.1 SOAP 通信文の例 ...................................................................................................................................................... 29

8.35 書式提出[ITI-35] ................................................................................................................................................... 31
8.35.1 範囲 ............................................................................................................................................................... 31
8.35.2 使用例役割 .................................................................................................................................................... 31
8.35.3 参照規格 ........................................................................................................................................................ 31
8.35.4 相互作用図 .................................................................................................................................................... 32
8.35.4.1 書式提出 .................................................................................................................................................................. 32
8.35.4.2 書式提出応答 ........................................................................................................................................................... 33

8.35.5 プロトコル要求事項 ......................................................................................................................................... 33
8.35.5.1 SOAP 通信文の例 ...................................................................................................................................................... 34

8.35.6 安全の考慮 ..................................................................................................................................................... 35
8.36 書式保存 [ITI-36].................................................................................................................................................. 36
8.36.1 範囲 ............................................................................................................................................................... 36
8.36.2 使用例役割 .................................................................................................................................................... 36
8.36.3 参照規格 ........................................................................................................................................................ 36
8.36.4 相互作用図 .................................................................................................................................................... 36
8.36.4.1 書式保管 .................................................................................................................................................................. 37
8.36.4.2 書式保管応答 ........................................................................................................................................................... 37

8.36.5 プロトコル要求事項 ......................................................................................................................................... 38
8.36.5.1 SOAP 通信文の例 ...................................................................................................................................................... 39

8.36.6 安全の考慮 ..................................................................................................................................................... 40
8.37 明確化情報取得（RETRIEVE CLARIFICATIONS）[ITI-37] ............................................................................................. 41
8.37.1 範囲 ............................................................................................................................................................... 41
8.37.2 使用例役割 .................................................................................................................................................... 41
8.37.3 参照する標準 .................................................................................................................................................. 41
8.37.4 相互作用図 .................................................................................................................................................... 41
8.37.4.1 明確化情報取得要求................................................................................................................................................. 42
8.37.4.2 明確化要求応答 ........................................................................................................................................................ 44

8.37.5 プロトコル要求事項 .......................................................................................................................................... 45
8.37.5.1 SOAP 通信文の例 ................................................................................................................................................... 45

付録 A

RFD 実装上の留意点 .................................................................................................................................. 47

A.1 データ収集用紙の留意点 ..................................................................................................................................... 47

A.1.1 収集データ項目の名称、語彙 ...................................................................................................................... 47
A.1.2 収集データ項目の一例 ................................................................................................................................. 47
A.2 我が国での RFD 実装例 ........................................................................................................................................ 50
A.3 実装に適用可能なその他の統合プロファイル ...................................................................................................... 53

A.3.1 IHE 医療の質・研究・公衆衛生領域（Quality, Research and Public Health (QRPH)）の臨床研究書類（Clinical Research Document, CRD） ................................................................................................................. 53
A.3.2 IHE 医療の質・研究・公衆衛生領域（Quality, Research and Public Health (QRPH)）の薬剤安全性報告（Drug Safety Content, DSC） .......................................................................................................................... 53
付録 B

監査通信文の例.......................................................................................................................................... 54___________________________________________________________________________________________________
3

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

B.1 書式取得（RETRIEVE FORM）[ITI-34] 監査通信文 ............................................................................................ 54

B.1.1 書式記入役監査通信文： ............................................................................................................................. 54
B.1.2 書式管理役監査通信文： ............................................................................................................................. 56
B.1.3 書式処理役監査通信文： ............................................................................................................................. 57
B.2 書式提出（SUBMIT FORM）[ITI-35] 監査通信文 ................................................................................................. 59

B.2.1 書式記入役監査通信文： ............................................................................................................................... 59
B.2.2 書式受領役監査通信文： ............................................................................................................................... 60
B.2.3 書式処理役監査通信文： ............................................................................................................................... 61
B.3 書式保存（ARCHIVE FORM）[ITI-36] 監査通信文 ............................................................................................... 62

B.3.1 書式記入役監査通信文： ............................................................................................................................... 63
B.3.2 書式保存監査通信文： ................................................................................................................................... 64___________________________________________________________________________________________________
4データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________

1 はじめにデータ入力用書式取得・提出に関する仕様（Retrieve Form for Data Capture Integration Profile、RFD）は IHE（Integrating
the Healthcare Enterprise）活動の成果であり、国規模の疾患データベース、各種医療・医学の学術団体が作成する疾患
や検査・治療などについてのデータベース（がん登録、心臓病登録、糖尿病登録、など）、国や自治体による、医薬品の副作用報告、医療機器の動作異常や事故の報告、伝染病・感染症の届け出、などに広く使用できる。RFD が支援するこれらの業務により、疾患とその診断と治療の実情の把握、ならびに、 医療政策上の意思決定に資する医療統計の提供、公衆衛生あるいは医療安全の向上、などを通じて、医療の質の向上に寄与することを目的としている。RFD は、国際的な活動を行っている IHE により、国際的に使用しうる業務手順として定められており、国際的な活動にも適している。
わが国でも従来から法令にて定められた医療上の届出に加え、疾患や疾患の診療に関する全国的データベースの構築が大きな関心の的となっている。RFD の様な標準的な技術的枠組みの提供により、データベース作成側、データ提出側の双方にとって、書式とデータの送受信の実装が容易となり、データベース維持・管理の負担が効率化されると思われる。
RFD の様な標準が無い状況では、データ受取り側と、データ提出側医療機関とが、医療機関が使用している医療情報システム（の類型）毎に、書式とデータの通信手順を個別に構築せねばならず、使用する情報システムの作成・維持・管理が複雑化することが懸念される。RFD はこの様な状況を効率化できると期待される。
本規格の国際版の作成主体である IHE 活動の目的は、患者の診療にあたっては、医学的判断に必要な全ての情報が、正確で医療専門家が必要とするときにはいつでも利用可能であるようにし、医療の質の向上に役立てることである。特定の臨床上の目的を達成するため、国際標準により確定された通信文規格を実装する際の技術的枠組み（テクニカルフレームワーク）、すなわち、統合プロファイル（Integration Profile、IP）の集合、を定めている。統合プロファイルとは、医療の領域ごとのあるまとまった一つの業務を遂行するために統合された、機能部品（アクタ、actor）の集合とこのアクタ間の相互作用の集合である。
IHE は新しい標準を定めない。むしろ、既存の標準、および他の適切な規格の使用を、これらの規格が該当する領域で統合的に使用できる様に、必要に応じて標準に定められた項目の設定方法に制限をかける。すなわち、IHE は実装の枠組みであり、標準自体ではない。IHE は、いわば、医療情報統合のための、「標準規格使用法」の標準である。
RFD は IHE の IT 基盤領域テクニカルフレームワークの一部をなす。IHE テクニカルフレームワークは統合プロファイルの集合であり、散在する医療システムを構成する機能部品（アクタ、actor）を、もっぱら医療機関における情報連携の観点から、定義するものである。現状では、ATSM, DICOM®, HL7®, IETF, ISO, OASIS, W3C 規格に準拠して協働するアクタと、それらの間の通信、すなわち、トランザクション、の集合である。

2. 規格の適用範囲
医療機関からデータを収集し、分析して医療あるいは公衆衛生の向上に役立てることを意図している行政機関や地方公共団体、医療・医学の学術団体、および、このようなデータ収集に協力する医療機関に適用可能である。

2.1 製品への実装
開発者には製品に実装する IHE アクタとトランザクションを選択する決断には三つの水準のオプションがある:⚫ システムにどのアクタを使用するか（一個のシステムに複数のアクタが使える）決める。
⚫ 個々のアクタについて、どの統合プロファイルに使うかを決める。
⚫ 個々のアクタとプロファイルについて、どのオプションを使用するか決める。
使用可能にしたい統合プロファイルには、必須のトランザクションを全て実装しなければならない。
実装する販売者は、任意の製品について、使用するアクタ、統合プロファイル、オプションが記された記述を提供しなければならない。

___________________________________________________________________________________________________
5データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________

一般に、製品にはいずれか一個のアクタ、あるいは、アクタの組み合わせが使用される。二個以上のアクタが一括されたとき、製品の機能を支える必要な情報の流れが可能であれば、アクタ間の内部交信は十分と見なされる。たとえば、必要な患者識別の対応付け情報を患者識別子相互参照管理役から取得するため、状況管理役は患者識別子相互参照消費役を使用する。この様な内部交信の正確な機構は IHE テクニカルフレームワークの範囲外である。
複数のアクタが一個の製品に一括されて実装される場合、製品が使用可能とするアクタのそれぞれから始まる、あるいは、終わる全てのトランザクションが、使用可能でなければならない（すなわち、IHE トランザクションは、製品の外部にインターフェースを与えられねばならない）。

2.2

著作権許諾

本規格の多くの部分は、IHE IT 基盤テクニカルフレームワークの RFD の和訳からなる。この部分についての著作権はIHE International Inc.にある。和訳、あるいは、日本 IHE 協会が作成した部分についての著作権は日本 IHE 協会が有している。本規格は無料で自由に配布できるが、IHE International Inc.と日本 IHE 協会の著作権は放棄されない。
Health Level Seven, Inc.は IHE に HL7 規格の表を複製する許可をあたえている。米国電気製品製造者連盟（National
Electrical Manufacturers Association, NEMA）は DICOM 規格の一部を IHE に含むことの許可を与えている。

3 用語と定義
3.1 用語テクニカルフレームワークの構想を提示すため、以下の用語を使用し、IHE テクニカルフレームワークが依拠する標準規格の適用法を明示する。
アクタ

actor
施設の運用活動と関連する情報を、生成、管理、あるいは、作用する情報システムまたは、情報システムの一要素である。

トランザクション

transaction
標準に依拠した通信文により、要求された情報を伝達するアクタの間の相互作用である。

統合プロファイル Integration Profile
一つのまとまった業務を実行するために必要となるアクタとアクタ間のトランザクションの集合。
依存

Dependence
1 つの統合プロファイルの実装に、他の統合プロファイルに定義された機能が前提的に必要な場合に、依存が有ると言う。

書式管理役

Form Manager
書式取得要求にもとづき、書式記入役に書式を供給するアクタ。

書式記入役

Form Filler
書式管理役から、必要に応じて必要なとき書式を取得し、データを入力するアクタ

書式受領役

Form Receiver
書式記入役から、完成された、あるいは、部分的に完成された書式個別事例データ（forms instancedata）を受領し処理する。書式受領役の処理は、統合プロファイルの範囲外で、書式受領役を整備す
る側、すなわち、データ収集主催者が目的に応じて定める。

___________________________________________________________________________________________________
6

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

書式保管庫

Form Archiver
完成された、あるいは、一部完成された書式個別事例データ（forms instance data）を受けとり、これを保存するアクタ

書式処理役

Form Processor
統合された書式管理アクタと書式受領アクタである。これらのアクタのすべてのトランザクションとオプ
ションを使用可能とする。

4. 略語
本規格と関連のある略語を以下に列挙する
EPR

Endpoint Reference の略語。Web サービスのサービス先アドレスの指定に使える情報をカプセル化した XML である。メッセージの送信先アドレス、メッセージの転送経路指定に必要な任意の追加パラメータ（リファレンス・パラメータ）、オプションのサービスに関するメタデータ（WSDL や WS-Policy など）が含まれる。WS-Addressing を参照。

HIS

病院情報システムの略語。医学、医療が高度化するに伴い、医療情報も多様化し増大してきたため、コンピュータを用いて病院内情報を合理化するシステム。電子カルテシステム，オーダエントリーシス
ム、医事会計システムなどの総称。

HTML

Hyper Text Markup Language の略語。ハイパーテキストを記述するためのマークアップ言語の 1 つである。ウェブページを表現するために用いられる。ハイパーリンクや画像等のマルチメディアを埋め込
むハイパーテキストとしての機能、見出しや段落といったドキュメントの抽象構造、フォントや文字色の指定などの見た目の指定、などの機能がある。W3C が使用の勧告を行っている。

HTTP

Hypertext Transfer Protocol の略語。 主にウェブブラウザとウエブサーバとの間での送受信に用いられるプロトコル。

IHE

Integrating the Healthcare Enterprise の略語。医療情報統合のための、「標準規格使用法」の標
準。これを作成する組織とその活動も指す。

RFD

Retrieve Form for Data Capture の略語。日本語表記は「データ収集書式取得・提出に関する仕様」

SOAP

TCP/IP 上の HTTP(S)で主に使用されるプロトコル。ウェブサービスに有効な手段の一つである。XML
を使用して通信文が表現される。

TLS

Transport Layer Security の略語。インターネットなどのコンピュータネットワークにおいてセキュリティを要求される通信を行うためのプロトコルである。通信相手の認証、通信内容の暗号化、改竄の検出、などの機能を提供する。
World Wide Web Consortium の略語。インターネット（World Wide Web）で使用される各種技術の標準化を推進する為に設立された標準化団体で、非営利団体として活動している。

W3C

WS-Addressing

Web Services Addressing の略語。ウェブサービスがアドレス指定情報をやりとりするための、転送手段から独立した機構をもつ仕様である。

XForms

ウェブフォームなどの XML データのためのユーザインタフェースやデータ処理モデルを定義する仕様である。XForms は高品質のウェブフォームを比較的簡単に作成できると言われている。現在の___________________________________________________________________________________________________
7

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

XML

XHTML

XForms 1.1 は 2009 年 10 月 20 日に W3C 勧告となった。
Extensible Markup Language の略称。任意の用途向けの言語に拡張することを容易としたことが特徴のマークアップ言語の総称である。W3 が策定し使用を勧告している。
Extensible HyperText Markup Language の略語。HTML を XML の文法で定義しなおしたマークアッ
プ言語である。

5. 要求事項
本規格は以下のIHE IT基盤領域のテクニカルフレームワークの一部を転載し、我が国の実装例を追加したものである。このため以下の適合する部分に準拠せねばならない。
IHE ITI TF Vol. 1 Rev 14, Final Text, 2017年7月4日
2.2.17 節 Retrieve Form for Data Capture (RFD)
17 節
Retrieve Form for Data Capture (RFD)
IHE ITI TF Vol. 2b Rev 14, Final Text, 2017年7月4日
3.34節 Retrieve Form [ITI-34]
3.35節 Submit Form [ITI-35]
3.36節 Archive Form [ITI-36]
3.37節 Retrieve Clarifications [ITI-37]
IHE ITI TF Vol. 2x Rev 14, Final Text, 2017年7月4日
Appendix A: Web Service Definition for Retrieve Specific Information for Display and
Retrieve Document for Display Transaction
Appendix B: Definition of Document Unique Ids
Appendix V: Web Services in IHE Transactions
本規格に使用されるトランザクションは以下の標準を使用する。
標準に課す制限は、本節以降に記載される。
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 Recommendation 20 October 2009. https://www.w3.org/TR/xforms11/
XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition). A ReFormulation of HTML 4 in XML 1.0.
W3C Recommendation 26 January 2000, revised 1 August 2002.
http://www.w3.org/TR/xhtml1.
XHTML™ Basic. W3C Recommendation 19 December 2000.
http://www.w3.org/TR/xhtml-basic.

6

データ入力用書式取得・提出に関する仕様（Retrieve Form for Data Capture Integration Profile, RFD）___________________________________________________________________________________________________
8データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________の概要
RFD は外部システムが要求する項目に適合するように、使用中のアプリケーション（例えば電子カルテなど）の中でデータを収集する方法を提供するものである。この RFD の枠組みを利用すると、データ提出者は現在使用中のアプリケーション
内にとどまったまま、書式が保存してある外部サーバ（書式管理役 Form Manager）から書式を取得し、データ入力を完成して（書式記入役 Form Filler）、外部のサーバ（書式保管庫 Form Receiver）へデータを送信できるようになる。
RFD は提出されたデータの誤り、不完全性、矛盾を指摘し、データの訂正や追加を行う一般的な方法を与える。指摘された誤りなどの情報は、データ提出側がデータ収集側へ取得にいくように RFD は定めている。このような訂正を可能とする機構と必要な制御については述べない。
RFD では、外部機関がその領域で適切な方法でデータ入力書式（調査書式）を提供するものとする。表示アプリケーショ
ンが行うべき業務を極力減らし、書式を完成するのに必要な記述をもつ、完全に機能する調査書式を外部機関が提供することを、このプロファイルは前提としている。RFD は完成した調査書式のコピーの保管を可能にする。
RFD の多くの潜在的な用途では、ホストアプリケーションのデータベースから書式に動的に値を事前に入力すること、つまり、書式の入力欄にホストアプリケーションのデータベースから選んだ適切な値が入力された状態で書式を記入者に提供することを、必要とする。 RFD は自動書式集計を可能にし、これを達成するための一般的なメカニズムを提供する。しかし、この仕様は、内容についての問題を規定せず、標準的な語彙や意味的な相互運用性を可能にする他の機能についても規定しない。
特定の領域群－臨床研究、医薬品安全、生物学的調査－では、内容の特定、RFD で動作する既存の標準の評価と推奨などにより、RFD の上にシステムを構築することになろう。RFD は基盤となる仕様として各領域独自の内容に関する標準を統合し、より大きな相互運用性を達成する。

6.1 使用例
以下の使用例はこの仕様が如何に種々の専門領域で使用できるかを示す。RFD はこれらのすべての使用例を可能にするが、RFD は実装方法を規定しない。医療のある領域固有の将来の IHE 統合プロファイル（仕様）では、RFD の使用とデータオブジェクトの規定の両方を指定する各領域に特化した統合プロファイルの作成が期待される。
ここに記す使用例は特記が無い限り、国際 IHE によるもので、米国での事例であり、わが国での事例ではないが、わが国にもあてはまる例である。
6.1.1 探索的新薬治験の使用例
臨床治験使用例の状況は臨床研究と患者の療養とが並行して行われる医師の実地診療である。Holbin 医療グループは、
多数の施設を有し、多種の専門からなる 100 名以上の医師を雇う臨床施設である。Holbin の社長（CEO）は製薬会社が支援する臨床試験に研究施設として参加するよう、医師に奨励している: Holbin は臨床研究活動を支援するため、研究コー
ディネータ 12 名、うち大部分は登録看護師（RN）で、事務員とデータ入力支援者も含む研究部門を擁している。Holbin 医療グループは電子化健康録（EHR）を使用し、臨床治験活動を記録するため、電子的データ取得システム（EDC）を支援
会社からいくつかもらっている（ここには EHR は患者の療養を記述する主たる場所となるあらゆるアプリケーションで患者療養の記録を取り出せるものとする。このため、今日では厳格には EHR でないものも含まれるが、ここにの目的には役立つ）。
Holbin の臨床治験への参加は、研究スポンサからの提案要求書（RFP）を受け取ったときから始まる。以下に手順を示す:✓ 研究コーディネータの Patricia Zone RN は、RFP を事業上の有用性、臨床的適切性に基づいて評価し、これに応募すると決め、スポンサに RFD を返送する。
✓ スポンサから臨床治験の施設として選ばれた後、#1234 と識別される。法令規制上必要な書類をスポンサに提供する。
___________________________________________________________________________________________________
9データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________

✓
✓

✓
✓
✓

主任研究者とされた医師とその他の研究職員はスポンサから試験計画に特異的な訓練を受ける。
治験準備期間に、Patricia は研究手順について適切な安全策が行われているのを確認し、参加および除外基準に従って治験参加者を集め患者の受診日を予約し、データ取得と入力を管理し、付属するすべての経済的業務を行う。
Patricia は Holbin の患者の Corey Jones と連絡し、治験の参加を依頼し Corey は治験への参加を承認する。
Patricia は Corey を治験#1234 の対象者として EHR 患者索引を使用して EHR に登録する。Corey の研究のための来院を EHR の予約機能を使用して予定し、治験#1234 に関連する来院と印を付ける。
準備期間のあと、施設は臨床治験を開始し、診療の書類と治験に特異的な書類を作り始める。

この使用例は以下の、「現状」と「望ましい状況」の節に続き、RFD 実装前後での EDC を使用した患者の治験用来院中のデータ取得を記述する。
6.1.1.1 現状
Corey Jones は予定された治験来院で診療部に到着し、Patricia Zone と合い対面のインタビューをする。Patricia は使用者
認証後 EHR に入り、来院を書面で記録する－'Jones さんは治験#1234 に関係する治験用受診に来院した'。Patricia はJones さんと会話し、観察し、観察結果を紙に記述する。EHR で最近の検査結果を見て、これを症例報告書式（CRF）に記述する。EHR には書式の一部に該当するデータしか無く、残りはインタビューと観察から得られる（EHR でえられる臨床治験データの割合は治験必要データの 5-40％と見積もられている。最良の場合でも研究計画が要求するデータの部分セッ
トしか典型的には取得できない）。
完成した紙書類はデータ入力担当の Bob に渡される。Bob は CRF が治験#1234 と認識し、#1234 用の EDC システムを選択する。このシステムはスポンサから供給されたノートパソコンにあるが、インターネットを経由してスポンサの EDC システムと接続している。リング 3 個のバインダを棚から取り出し、このシステム使用法の”虎の巻”書類を探す。EDC アプリケーショ
ンに username とパスワードで認証を受けて入り、正しい電子的症例登録書式（eCRF）に該当の治験来院のデータを入れる。元の紙書類を処理すると、Bob はこの紙書類を、治験の永久記録の一部として箱（banker's box1）にしまう（連邦規則 21
CFR 312: 62 の要求事項をみたすため）。
治験#1234 に加え、Bob は 8 つの追加の EDC システムにデータ入力を行う。うち 5 個は専用ノートパソコン、3 つはインターネット接続である。インターネット接続の EDC システムは机で必要なスペースを少なくするが、それでも”虎の巻”使用説
明書の入ったリング 3 個のバインダが必要である。特定の治験のデータが対応するノートパソコンに入力したか確認するのは、それぞれに特定の認証儀式と特定の入力書式が必要な面倒な仕事である。Bob はこのようなやっかいなシステムに苛だっている。Bob は誠実な職員で仕事はいつも最新で貯めたりしない。多くの施設ではデータ入力係はしばらく CRF を持ったままで大抵は月に 2 回程度の入力、あるいは、治験モニタ来訪一週間前に入力するのが関の山である。
6.1.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 データベースからデータが予め適切な欄に（編集チェックを組み込めば）入れることもできる。書類を完成したら、Patricia は「提出」ボタンを押す。EHR システムは完成した書式を EDC に RFD を使用して送信する。書類のコピーが施設の臨床治験保管庫に治験の永久記録の一部として保存される。

1

定義は http: //www.archivisits.org/glossary/term_detaiks.asp?DefinitionKwy=1193 をみること。

___________________________________________________________________________________________________
10

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

6.1.2 公衆衛生報告使用例
6.1.2.1 公衆衛生シナリオ
6.1.2.1.1 現状
Smith さんは消化器症状で地域病院の救急部を受診した。医療提供者は試料を検査室に送った。検査室はクリプトスポリ
ジウムを検出した。検査室職員は週一回必要な公衆衛生報告のため検査室データベースに問合せる。症例が同定され、検査室情報システムからの情報を公衆衛生報告書式にコピーし、印刷して公衆衛生当局に送る。管轄内の医療機関から提出された報告書を公衆衛生当局の職員は閲覧し、多くのクリプトスポリジウム症例が地域の病院にいることを認識する。
追加の症例を監視する様に、地域の医療機関に注意が通知される。感染のあった地域に供給されている水が試験され、対応がなされる。しかし、紙書類による処理のため検出が遅れたため、多くの追加のクリプトスポリジウム症患者が発生した。
6.1.2.1.2 望ましい状況
Smith さんは消化器症状で地域病院の救急部を受診した。医療提供者は試料を検査室に送った。検査室はクリプトスポリ
ジウムを検出した。検査室システムはこの結果は公衆衛生報告が必要であるものと認識し、検査結果の確認が検査システ
ムで済むや否や、PHIN 標準を使用して DOH（厚生局）にレポートを送る。さらに、あるいは、代わりに、RFD プロファイル
を使用して Biowatch 公衆衛生システムから報告書式を取得する。症例報告書式が、EHR（電子健康録）から取ったデー
タを入れて、医療提供者に提示される。医療提供者は残りの追加データを入力して、このデータを公衆衛生当局へ電子的に送る。公衆衛生当局は多くの電子レポートを管轄の検査室や医療機関から受け取る。追加の症例を監視する様に、地域の医療機関に注意が通知される。感染のあった地域に供給されている水が試験され、対応がなされる。処理の自動化のために早期発見ができたので、追加のクリプトスポリジウム症患者は最小にできた。
6.1.3 薬物副作用報告・監視シナリオ
Cramp 医師は外来で患者を診察し、電子健康録（EHR）を利用して、患者が新しいスタチン薬の一種を服用していることを知る。診察で患者のふくらはぎの筋力低下を見つけ、医師はスタチンの副作用と気づく。診断のため総クレアチニンキナ－ゼ検査をオーダする。
6.1.3.1 現状
Cramp 医師は EHR を閉じて、インターネット閲覧ソフトにより http: //fda.gov/medwatch/を開く。FDA 書式 A3500「臨床診療のなかで自発的に気づかれた有害事象の任意通報」を持ってくる。案内ページや記入法のページを経て、実際の書式の最初のページに到達する。最初のページでは、患者識別子、発症時年齢または誕生日、体重を入力する。次のページには 7 項目の入力がある。事例の分類、転帰の分類、発症日、通知日、記述、関係のある検査所見、その他の関連のある病歴（最後の 3 つは文章入力）、である。3 頁目、4 頁目は製品の詳細を入力する、以後同様である。
6.1.3.2 望ましい状況
Cramp 医師は上記の様に患者を診察して EHR を利用する。問題を発見すると、”有害事象報告”ボタンを押して FDA 書
式 3500 を、EHR のインターフェースから、持ち込む。書式の患者基本情報欄はすでに埋められている。製品名は、現にEHR で使っている文脈の一部なので、適切な入力欄に自動的に入力される。Cramp 医師はその他の情報を入力し、直接
FDA Medwatch へ投稿する。
RFD は Medwatch から書式を取得し、表示し、FDA への書式返送を行う。このプロファイルでは EHR が書式のコピーを保持しておくか、EHR データを予め取得しておくか、については扱わないことに注意する。単に、EHR を使って、表示し、記入を完成し、返送するだけで十分である。EHR とその施設は、EHR の中に（記入した）書式のコピーを保存すると決める___________________________________________________________________________________________________
11

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

こともできるが、これはこのプロファイルの拡張であり、必須ではない。
6.1.4 我が国での薬剤副作用調査例
RFD のわが国での最初の実装が行われ、2017 年 6 月現在、実運用に入っている。概要を以下に記す。詳細は付録 A
A.2 節を参照のこと。
医科大学と研究支援機関は、2017 年より、糖尿病のリスク・ベネフィット調査を電子的に行っている。同医科大学病院の糖尿病患者に対して SS-MIX 標準化ストレージから処方、検査結果情報が取り込まれ、電子カルテシステム上で所見項目が記入され、併せて、ケースカードが作成される。病院ネットワークは外部とつながっていないため、たまったケースカード
を USB フラッシュメモリに掃出し、これを、外部とつながったアップローダ（RFD Form Filler および Form Archiver）が、研究支援機関のサーバ(RFD Form Receiver）に送る。このようにして、IHE RFD が実装され、実運用されている。

6.2 データのネットワーク提出に制限のある場合医療機関によっては、医療情報の医療機関外部への提供に厳しい規制があり、医療機関内から医療機関外へ RFD に適合する書式を取得する要求を出して書式を受けとり、書式へデータを入力し、そのままネットワーク通信によりデータを医療機関外へ提出することができない場合がある。この様な場合には、院内ネットワークと院外へ通じるネットワークの間で媒体によるデータ移送を行うことが考えられる。迅速な情報提出が必要な場合には、この過程を迅速に行うための運用の工夫などが必要となる。

7. RFD の機能概要
RFD 仕様（統合プロファイル）に含まれる機能単位であるアクタと、その間の通信であるトランザクションを以下に記す。
一つの統合プロファイルの実装に、他の統合プロファイルに定義された機能が前提的に必要な場合に、依存が有ると言う。
依存する統合プロファイルを使用可能とするには、前提的に必要な統合プロファイルに必要なトランザクションに加え、依存する統合プロファイルに必要なトランザクションも使用可能とせねばならない。以下の記述で依存がある場合にはその旨記載される。

7.1 アクタ・トランザクションの相互作用
図 7.1-1 に、データ収集書式取得・提出に関する仕様に直接含まれるアクタとこれらの間の関連するトランザクションを示す。他の統合プロファイルに参加することにより間接的に含まれるアクタは示されない。

___________________________________________________________________________________________________
12

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

図 7.1-1: データ収集書式回収・提出アクタ図
表 7.1-1 に、データ収集書式取得・提出に関する仕様に直接含まれるアクタのそれぞれに対するトランザクションを示す。
この統合プロファイルが使用可能と実装が主張するには必須（"R"と表記）のトランザクションを実行できねばならない。"O"と表記されたトランザクションはオプションである。この統合プロファイルに定義され、実装が選択可能なオプションの完全な一覧は以下である。
表 7.1-1: データ収集書式取得・提出統合プロファイル－アクタとトランザクション
アクタ
書式記入役
Form Filler

書式管理役
From Manager
書式受領役
Form Receiver
書式保存役
Form Archiver
書式処理役
Form Processor

トランザクション
書式取得[ITI-34] Retrieve Form
書式提出[ITI-35] Submit Form
書式保存[ITI-36] Archive Form
明確化情報取得[ITI-37] Retrieve Clarifications
書式取得[ITI-34] Retrieve Form
明確化情報取得[ITI-37] Retrieve Clarifications
書式提出[ITI-35] Submit Form

必須度
R
R
O
O
R
R
R

本書の節番号
8.34
8.35
8.36
8.37
8.34
8.37
8.35

書式保存[ITI-36] Archive Form

R

8.36

書式取得[ITI-34] Retrieve Form
書式提出[ITI-35] Submit Form
明確化情報取得[ITI-37] Retrieve Clarifications

R
R
R

8.34
8.35
8.37

7.2 アクタ7.2.1 書式管理役（Form Manager）
書式管理役は、書式取得要求にもとづき、書式記入役に書式を供給する。ある場合には、書式記入役は単に書式の集合から一つの書式のみを返送するが、他の場合には、書式取得要求でもたらされた状況の情報にもとづいて、書式を選択したり、組み上げたりする。さらには、書式保管庫についての追加の情報が書式記入役からもたらされるか否かにより、書式の集合から取得した書式を変更したりする。書式管理役は書式の取得要求に答えて、書式とともに書式事例 ID（forminstance ID、データが記入された個々の書式を識別するもの）を返すことができる。書式管理役は書式を構成して、記入された書式データを書式受領役に提出する。

___________________________________________________________________________________________________
13

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

7.2.2 書式記入役 (Form Filler)
書式記入役は書式管理役から、必要に応じて必要なとき書式を取得する。書式を要求するとき、書式記入役は、事前に書式に入れておく xml データの提供による EHR 状況情報と、さらに、書式の選択を容易にする業務流れのデータもオプ
ションで要求に加えて送り、書式管理役がこの情報を使用して書式の選択やデータ事前入力ができるようにする。
書式記入役は書式保管庫アクタを指定することができる。書式記入役に指定された書式保管庫は、書式管理役が指定する書式保管庫に加え存在する、別の保管庫とされる。
7.2.3 書式受領役 (Form Receiver)
書式受領役は、書式記入役からの、完成された、あるいは、部分的に完成された書式個別事例データ（forms instancedata）を受領し処理する。書式受領役の処理は、統合プロファイルの範囲外で、書式受領役を整備する側、すなわち、データ収集主催者が目的に応じて定める。
7.2.4 書式保管庫 (Form Archiver)
書式保管庫は完成された、あるいは、一部完成された書式個別事例データ（forms instance data）を受けとり、これを保存の目的で蓄積する。
7.2.5 書式処理役 (Form Processor)
書式処理役は、統合された書式管理役と書式受領役で、これらのアクタのすべてのトランザクションとオプションを使用可能とする。

7.3 トランザクション
7.3.1 書式取得（Retrieve Form）
書式取得トランザクションは、書式管理役から書式記入役へ書式識別子を伝える。このトランザクションではオプションで書式記入役が書式保管庫を指定できる。状況情報と業務流れ情報を含む追加情報が要求とともにもたらされることがあり、要求された書式の選択と事前の書式への値入力を容易にする。割り当てられた書式識別子の値により、書式が定まる。書
式識別子の割り当てはプロファイルには定めないが、書式記入役と書式管理役との間で、必要な設定作業の一部として、割り当てが行われると思われる。
7.3.2 書式提出（Submit Form）
書式提出トランザクションは、書式記入役が書式個別事例データ（form instance data）を書式受領役に提出できるようにする。
7.3.3 書式保管（Archive Form）
書式保管トランザクションは、書式記入役が書式個別データ（form instance data）を書式保管庫に提出できるようにする。
7.3.4 明確化情報取得 （Retrieve Clarifications）
明確化情報取得トランザクションは、書式記入役が書式管理役、あるいは、書式処理役から任意の組織のデータ明確化
情報の一組を要求できるようにする。割り付けられた組織識別子の値により、データ明確化情報の命名されたオプション
書式が決まる。組織識別子の割り当ては統合プロファイルには定めないが、書式記入役と書式管理役との間に必要な設定作業の一部として割り当てが行われると思われる。
___________________________________________________________________________________________________
14

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

7.4 データ取得書式取得・提出のオプション
この統合プロファイルに選択可能なオプションを、適用されるアクタとともに、表 3.4-1 に示す。
表 7.4-1: アクタとオプション
アクタ
オプション
Archive Form
書式記入役
Data Clarifications
Form Filler
XFormsXForms
書式管理役 Form Manager
XForms
書式処理役 Form Processor

本書の節
8.36
8.37
7.4.3.
7.4.3
7.4.3

7.4.1 書式保存オプション （Archive Form）
書式取得オプションは、書式記入役が、保存の目的で、書式個別事例データを書式保管庫に提出できるようにする。
7.4.2 デ－タ明確化オプション（Data Clarifications Option）
データ明確化オプションは、書式記入役が書式管理役から明確化情報を取得し、以前に提出したデータを更新して、書式受領役に提出できるようにする。
7.4.3 XForms オプション
XForms オプションは、書式記入役と書式管理役が XForm 書式で書式を交換できるようにする。このオプションに課される制限については 8.34.4.1 節を見ること。

7.5 RFD の処理流れ
この節では、書式がデータ収集用に取得され、部分的に完成、あるいは、完成した後で提出される際の、処理と情報の流れを記述する。書式が完成したか否かの基準はこのプロファイルの範囲外である。
五つの場合が区別できる。
場合 1: これは、既知の書式 ID (formID)を使用して書式を取得する、単純な場合である。
書式の識別子である書式 ID は、臨床治験に参加するときの様に、書式記入役に知られている。書式 ID 値は書式索引の公表、あるいは、個人的な連絡によっても、連絡できる。書式 ID を取得する方法はこのプロファイルの範囲外だが、書式取得要求の前提である。
二つのアクタ設定が可能である：⚫ 書式管理役と書式受領役が群化され書式源として機能する（図 7.5－1）。
⚫ 書式処理役が存在する（図 7.5‐1b）。
書式記入役は書式管理役または書式処理役に書式取得要求を送る。書式管理役または書式処理役は、要求された書式を返すか、書式が使用できない旨のエラーを返す。書式が返されたとき、書式記入役は書式個
別事例データを、書式提出トランザクションを使用して書式受領役、または、書式処理役に、提出する。書式
管理役と書式受領役は群化されているので、両者の間に部分完成の書式の場合の様に通信があるかも知れないが、これは内部通信であり、IHE トランザクションではない。

___________________________________________________________________________________________________
15

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

図 7.5-1: 場合 1: 書式取得と書式提出；書式管理役は書式受領役と一括化___________________________________________________________________________________________________
16

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

図 7.5‐1b: 場合 1: 書式取得と書式提出；書式処理役
場合 2: これは、書式受領役が独立（すなわち、書式管理役と群化されていない）している場合を説明する（図 7.5-2）。
この図説では二つの書式受領役がある: 1) 書式記入役と群化された中間の書式受領役； 2) 最終の、群化されていない
書式受領役、である。
書式の識別子である書式 ID は書式記入役に知られている:一つのシステム内に、途中で書式を保存できる書式記入役と書式受領役がある。これとは別に、最終的に書式データを保存する、別システム上の書式受領役がある。
書式記入役は書式管理役に書式取得要求を送る。書式管理役は、要求された書式を返すか、あるいは、書式が使用できない旨のエラーを返す。書式が返されたとき、書式記入役は部分的に完成した書式を中間の書式受領役に送る。この部
分完成した書式は、中間の書式管理役に当てたもう一つの書式取得要求で取得でき、最終的に完成された書式を、最終的に保存する孤立の、たとえば、国のデータ登録書の様な、書式受領役に提出できる。提出するための動作は書式によって制御されるので、提出後の動作を書式の選択によって、あるいは、新たな生成により、書式取得トランザクションの処理の中で、望む動作を定める責任が書式管理役にある。

___________________________________________________________________________________________________
17

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

図 7.5-2: 場合 2: 書式取得と書式提出；書式管理役は書式受領役と別。
場合 3: この場合は、書式記入役が保存オプションを使用する（図 7.5-3）。
書式記入役は、指定された書式保管庫に書式を保存する必要がある旨を示して、書式取得要求を書式管理役に出す。
書式管理役は、要求された書式を返すか、書式が使用できない旨のエラーを返す。書式管理役は書式記入役の書式取得要求に指定された書式保管庫に書式保存のトランザクションを実行できる様に書式を構成する。書式が戻され次いで提出されるとき、書式個別事例データは書式受領役と書式保管庫に提出される。

___________________________________________________________________________________________________
18

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

図 7.5-3: 場合 3: 書式取得、提出、と書式保存提出
例 4: この例は、書式 ID が事前にわからない場合の問題を解決するため書式デザインを使う一方法を示す（図 7.5-4）。
書式の識別子である、書式 ID（formID）が書式記入役にわかっていないが、内容値（名前、値）の対の一セットがわかっている。これらの値を入力すべき内容書式は書式 ID を持っている。内容書式の事例データで集められた情報を書式管理役が使用して、書式記入役に戻すべきデータ収集書式を決める。
書式記入役は、実際のデータ収集書式を書式管理役が決める補助となる情報を集める内容書式を請求できる情報は持っている。書式記入役は内容書式の一事例を完成し、これを書式受領役に提出すると、書式受領役は新しい事例データ
あるいは、新しい書式を戻す。

図 7.5-4: 場合 4: 書式取得；書式提出
例 5: この例では、書式記入役はデータ明確化オプションが使用可能である（図 7.5-5, 7.5-6）。

___________________________________________________________________________________________________
19

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

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

図 7.5-5: 場合 5: データ明確化オプションが使用可能な書式記入役

図 7.5-6: 場合 5: データ明確化オプションが使用可能な書式記入役

7.6 安全の考慮___________________________________________________________________________________________________
20

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

7.6.1 RFD リスク分析とリスク評価
RFD のリスク分析には、資産、脅威と軽減策がある。リスクデータの完全な一覧は IHE に保存され、IHE から取得可能である2。
リスク評価の目的は、RFD アクタを実装する際、販売者が考慮するよう助言されるリスクのいくつかを知らせることにある。
多くのリスクは IHE プロファイルでは解決できず、かわりに、軽減策の責任は、販売者、時に連携圏、個々の施設や実装
者に転嫁されることを、販売者に助言する。この様な場合、IHE は以下の節を使用してリスクを受ける団体に通知して、IHE の責任を果たす。
7.6.2 安全考慮の概説
IHE トランザクションは、個人情報保護法、これに関連する法令やガイドラインで示される規制に則り保護されねばならない情報を、しばしば含む。IHE には以下に示す 2，3 の安全とプライバシに焦点を定めたプロファイルがある。RFD の様に
特別のプライバシ保護策を持っていない統合プロファイルは、一個以上の安全プロファイルと適切にくみあわされるものとしている。:⚫

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

⚫

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

⚫

ATNA の実装には時刻同期統合プロファイル（CT）に依存するので、ATNA と同時に CT が必要である。

⚫

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

⚫

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

⚫

施設間使用者確認統合プロファイル(XUA)は、自システムに接続してきた相手方や自動実行機構が誰であるか、相手方で認証されているか、どの様な権限があるか、などを確認する手段を与える。

実装者は自製品の安全要求を満たすためこれらの IHE 統合プロファイルを使うことができる。施設は、各施設の要望を満たし規制要求事項を遵守するため、方針と業務流れを実装しなければならない。
7.6.3 推奨
高衝撃のリスクには、正確性の過誤、データとの間での相違、商業秘密の公開、がある。このプロファイルには軽減策がある。
M1. 使用者が間違った書式を取得した場合には、書式を破棄する。書式取得トランザクションは”無国籍”（=個人情報を含まない）なので、書式の破棄は何の問題も起こらない。
M2. XForm オプションを使用する場合、データモデルの図式証明は XForm モデルが提供する。XForm プラグインは
XForm の処理と表示の責任をおうが、これはこの統合プロファイルの範囲外である。
M3. TLS の実装は可能で、プライバシ保護と施設使用者認証を要する連携圏や施設はこれを使用できる。（実装物はTLS を実装せねばならない。これを有効にする決定は連携圏と施設に任される）
2

リスク分析データは以下にある：ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr5-20072008/Technical_Cmte/Profile_Work/RFD/
RFD%20Risk%20Analysis%202007-05-15.xls___________________________________________________________________________________________________
21

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

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

___________________________________________________________________________________________________
22

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

8 RFD のトランザクションの詳細
以下では IHE ITI テクニカルフレームワーク原本（英語）と節番号および図番号を同じにして、読者の利便を図り混乱を避けるため、意図的に節番号は 34 から始めている。
章番号は原本では 3 であるが、本規格では 8 であるので、原本を参照する際には注意する。
（8.1 - 8.33 は意図的に空白）

8.34 書式取得[ITI-34]
この節は、IHE IT 基盤テクニカルフレームワークの ITI-34 トランザクションに対応する。ITI-34 トランザクションは書式記入
役と書式処理役に使用される。
8.34.1 範囲
このトランザクションには書式記入役の書式管理役ないし書式処理役からの書式取得が含まれる。書式記入役は FormIDを持っており、さらに業務流れに関する情報を持つことがあるが、これらの取得方法はこのトランザクションの範囲外である。
書式記入役は以前に提出した書式を参照する書式事例 id（form instance id）を持つ。書式管理役や書式処理役は任意の FormID に対応する書式、または、URL とオプションで書式事例 id（form instanc id）を戻すか、さもなくば、エラーを戻す。
書式は以下では書式オプションとして定められ制限をかけられる。
8.34.2 使用例役割

アクタ：書式記入役
役割：書式のデータ欄への入力完成を可能とする、書式表示と編集システム
アクタ：書式管理役
役割：特定の FormID を提供する要求に基づいて書式を提供し、オプションで追加の業務流れを提供する。書式データは
書式受領役に提出される。
アクタ：書式処理役
役割：特定の FormID を提供する要求に基づいて書式を提供し、オプションで追加の業務流れを提供する。このアクタからの書式データは自身に提出されねばならない。
8.34.3 参照規格
このトランザクションの実装者は ITI TF-2x: 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___________________________________________________________________________________________________
23

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

2000. http://www.w3.org/TR/REC-xml.
ITI TF-2x: Appendix V Web Services for IHE Transactions
XForms 1.1. W3C Recommendation 20 October 2009. https://www.w3.org/TR/xforms11/
XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition). A ReFormulation of HTML 4 in XML 1.0.
W3C Recommendation 26 January 2000, revised 1 August 2002.
http://www.w3.org/TR/xhtml1.
XHTML™ Basic. W3C Recommendation 19 December 2000.
http://www.w3.org/TR/xhtml-basic.
8.34.4 相互作用図

8.34.4.1 書式取得請求
書式取得には、書式記入役の書式管理、または、書式処理役への書式請求が含まれる。書類記入役は業務流れデータと事前記入データを供給せねばならない。書式記入役は書式事例(instance)id を提供することができる。
書式取得要求は archiveURL 値を、空値として、あるいは、書式保管役（Form Archiver）を指し示す URL として、提供せねばならない。詳細は 8.34.4.1.2 節を見ること。
書式記入役の状況（context）を表す様に適切に書式化された xml をもつ prepopData 引数を提供して、返送される書式の選択や生成に、書式記入役、あるいは、書式処理役が状況（context）情報を使用する様に、書式記入役が要求する。
prepopData 方式は内容プロファイルに任されている。この値は空値のこともある。
workflowData パラメータの状況要素を使用して、書式の選択や生成に使用する追加の業務流れ情報を書式記入役が提供する。状況要素の仕様は内容プロファイルに任されている。
書式取得要求への応答で、書式、あるいは、書式への参照が返され、書式事例（instance）id が返されることもある。
8.34.4.1.1 トリガーイベント
書式記入役は、人間による決定、あるいは、自動動作の規則を実行するアプリケーションにより、書式管理役あるいは書式処理役が有している書式を要求する。

___________________________________________________________________________________________________
24

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

8.34.4.1.2 通信文の意味
このトランザクションの実装者は ITI TF-2x: Appendix V: IHE トランザクション用ウェブサービスに記載された全ての要求事項に適合せねばならない。以下のパラメータがこのトランザクション用に指定されている。
REQ
R

説明
書式の入力欄を事前入力で使用するために書式記入役から提供される XML コンテキスト情報

workflowData

R

ワークフロー特有の値の xml 表
現formIDR

書式の識別子encodedResponseR

符号化された応答を返すかどうかを書式管理役に通知する期待される符号化された応答のタ
イプを指定する encodedResponseの XML 属性

パラメータ名称
prepopData

responseContentTypeOarchiveURL

R

書式記入役が Archive オプションを使用しているかどうかを書式管理役に通知する

contextR

ワークフローコンテキストの XML
指定

instanceID

R

以前に提出されたデータ事例（インスタンス）の id 値

値
この値は、ヌルか、適切に整形された XML
ドキュメントでなければならない
以降で定義する適切に整形された XML ド
キュメント
書式を識別する文字
列{true,false}
内容プロファイルで定義された値の文字列。
encodedResponse の値
が“false”の場合には指定してはならない
任意の書式記入役、識別される書式保管庫の URL、または、空文字列
内容プロファイルで定義された文字列、空値でもよい
以前に提出されたデータの事例を識別する
文字列、空値でもよい

prepopData パラメータの内容は IHE 内容プロファイルが指定する prepopData スキーマに規定されている。prepopData が
無 い と き に は 、 xsi:nill 属 性 は "true" に 設 定 せ ね ば な ら な い （ 補 助 資 料(ftp://ftp.ihe.net/TF_Implementation_Material/ITI/)を参照のこと ）。
workflowData パラメータの内容は、最小、以下の様でなければならない：<workflowData><formID>a String identifying the form</formID><encodedResponse>false</encodedResponse><archiveURL /><context/><instanceID/></workflowData>
encodedResponse パラメータが"true"のときのみ、respoonseContentType 属性が指定できる。responseContentType 属性の値は、書式管理役あるいは書式処理役からの応答の符号化を指定する。許容できる値は内容プロファイルで定められる。
これの使用例は、予期される応答が XML 書式か、XHTML 書式かを、指定するためである。以下はこの使用例である。
<workflowData>___________________________________________________________________________________________________
25

データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________<formID>a String identifying the form</formID><encodedResponse>false</encodedResponse><archiveURL/><context/><instanceID/></workflowData>
補助資料（ftp://ftp.ihe.net/TF_Implementation_Material/ITI/）にあるスキーマを見ること。workflowDataは、<context>要素のさらなる定義とともに、IHE内容プロファイルにより拡張されることがある。

8.34.4.1.3 期待される動作
書式取得要求を受け取ると、書式管理役あるいは書式処理役は要求を構文解析して、要求された応答をRetrieveFormResponse 要素で、エラーを SOAP Faults で、それぞれ、返さねばならない。書式管理役は書式または URLを、a) encodedRespsonse; b) fromID; c) あらゆる workflowData; d) オプションで提供される instanceID の値に基づいて、戻さねばならない。
encodedReponse が"true"の場合には、書式管理役あるいは書式処理役からの応答は、構造化（XML）あるいは非構造化（non-XML）要素のいずれかでなくてはならない。encodedReponse が"true"の場合には、分断された識別子ではないすべての停留アドレス（anchor address）は絶対 URI で構成されねばならない。
responseContentType 属性が指定された時には、書類管理役あるいは書類処理役の応答は 適切な内容タイプをもつ構
造化要素、たとえば、XML 書式定義あるいは XHTML 書式、でなければならない。書類管理役あるいは書類処理役は、
オプションの esponseContentType 属性を受けたとった場合はエラーを出してはならない。
encodedReponse が"false"の場合には、書式管理役あるいは書式処理役からの応答は、書式の取得と操作にブラウザで直接使用できる URL 要素でなければならない。
書式管理役あるいは書式処理役は書式事例 id（form instanceID）の値を割り付けて返すことが出来る。
要求の archiveURL パラメータに有効な URL を書式記入役が提供したときは、書式管理役ないし書式処理役は、書式提出時に書式保存（Archive Form）トランザクションを実行する書式と、事前に設定された、提出に伴う動作とを、返さねばならない。3.36 節「書式保存」に示すように、この追加の保存トランザクションは書式記入役と書式保管役との間で起こる。

書式記入役が prepopData パラメータでデータを提供した時には、書式管理役あるいは書式処理役は返すべき書式と予め埋めるべきデータ野を決めるためにこの情報を用いることができる。prepopData の正確な使用法と構造は IHE 内容プロフ
ァイルの出版までのばされる。
書式管理役あるいは書式処理役は workflowData パラメータ内の値、およびオプションで提供される instanceID を使用して、返すべき書式をきめ、書式のデータ野に予め値を入れる。
FormID の値は予め書式管理役あるいは書式処理役が割り付けて、命名済書式オプションの一つを用いて書式記入役に返す書式を識別する。書式管理役あるいは書式処理役は複数の命名済書式オプションを使用可能とするが、FormID のそれぞれには、使用可能な命名済書式オプションは一個だけである。
書式管理役あるいは書式処理役は、表 8.34.4.4.1.3-1 に定める SOAP fault を適切な場合に使用せねばならない。書式記
入役はここに示す値以外の値も受け取る能力がなければならない。

___________________________________________________________________________________________________
26

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

表 8.34.4.1.3-1:SOAP faults
エラーの説明コード
理由を示す文SenderRequired Information Missing
formID が無いなど、情報が欠損している
SenderUnknown formID
書式が存在しない
SOAP fault の例は以下である：<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>
8.34.4.1.4 安全の考慮
本書 7.6.3 の「安全の考慮」の緩和策の節に記す様に、終着点は自由に、追加のプライバシと保護のため、必要に応じてTLS を実装できる。内容プロファイルはデータの特質に応じて、ATNA の使用を要求することがある。
8.34.4.2 書式取得応答
8.34.4.2.1 トリガーイベント
書式所得要求に応じて、書式管理役あるいは書式処理役がこの通信文のきっかけを出す。
8.34.4.2.2 通信文の意味
書式、あるいは、URL が戻される。
以下のパラメータがこのトランザクションの応答に指定されている。
REQ
要素名
説明
form
R
書式の xml 要素コンテナ。
書式要素は、{Structured,
Unstructured, URL}のうちの一つを含まなければならず、instanceID も含んでもよいform/Structured
O[注 1]
エンコードされ、構造化された形式のコンテンツを返すための xml 要素コンテナ。

制限
urn:ihe:iti:rfd:2007:formDataType型の要素である。 従って、子要素のみを所持し、値は保持しない。

xs:any
この要素は、内容プロファイルによって更に制限される可能性がある。書式の要求が持つ
encodedResponse の値が true の場
合にのみ存在してもよい。

___________________________________________________________________________________________________
27

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

form/Unstructured

O[注 1]

エンコードされ、非構造化の、base64 符号化書式コン
テンツを返すための xml 要
素コンテナ。

form/URLO[注 2]

書式へのポインタを返すた
めの xml 要素コンテナ。

form/instanceID

O

contentType

R

書式事例（form instance）の値を含む xml 要素
書式要求の
encodedResponse の値がfalse の場合は、意味を持たない。

responseCode

R

定義なし

xs:base64Binary
この要素は、内容プロファイルによって更に制限される可能性がある。
書式の要求が持つencodedResponse の値が true の場
合にのみ存在してもよい。
xs:anyURI書式の要求が持つencodedResponse の値が false の場
合は必須である。
xs:string
xs:string
必須：ヌル値でもよい。
値は、内容プロファイルによって制約されるかもしれない。
xs:string
必須：ヌル値でもよい。
値は、内容プロファイルによって制約されるかもしれない。

注 1：書式要求（Form Request）が持つ encodedResponse の値が true の場合、二つのフィールドうちの一つが必須であり、URL フィールドの使用は禁止される。
注 2：書式要求（Form Request）が持つ encodedResponse の値が false の場合、URL フィールドは必須であり、Stuctured と Unstructured フィー
ルドの使用は禁止される。

8.34.4.2.3 期待される動作
書式記入役は、書式取得トランザクションの encodedResponse 値が False の場合は、返された URL の値から書式を取得しなければならない。
書式取得の encodedResponse の値にかかわらず、書式記入役は書式の提出に必要なフィールドに値を入力することが可能であり、ユーザとの対話のために書式を表示してもよい。
8.34.4.2.3.1 XHMTL 取扱い
書式管理役あるいは書式処理役は書式を返さねばならない。要求で encodedResponse 値が"false"のために、書式が URLとして返された時は、XHTML Basic、および、W3C XHTML 1.0 Recommendation の付録 C に記載された W3C 適合性ガ
イドラインを使用して、XHTML として書式化されねばならない。書式が構造化された内容として返されたなら、XHTML に変換可能でなければならない。すべての場合で、提出トランザクションおよび要求された保存トランザクションが使用可能
でなければならない。
8.34.4.2.3.2 XForm オプション
XForms オプションを使用可能とする書式管理役あるいは書式処理役は、応答として返された書式か、返された URL で参照される書式かによらず、XForms 1.1 に適合する書式を追加して返す能力を持たねばならない。XHTML Basic および、
W3C XHTML 1.0 Recommendation の付録 C に記載された W3C 適合性ガイドラインに従って、XForm のホスト言語は
XHTML Basic でなければならない。返された書式では提出トランザクションと全ての必須保存トランザクションをサポートし___________________________________________________________________________________________________
28

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

なければならない。
8.34.5 プロトコル要求事項
書式取得要求と応答は、ITI TF-2x: Appendix V に従って、同期ウェブサービス交換を使用して伝達せねばならない。
書式取得要求トランザクションは SOAP 1.2 を使用せねばならない。
WDSL 名前空間定義

これは、WSDL 定義に現れる順番に並べた、書類取得トランザクションの要求事項である。
⚫ 以下のデータ型が/definitions/types 節に読み込まれ（xds:import）ねばならない。
⚫ Namespace="urn:ihe:iti:rfd:2007", schema="RFD.xsd"⚫ 書式取得要求通信文の/definitions/message/part/@element 属性は、"ihe:Retrieve Form Request"として定義されねばならない。
⚫ 書式取得応答通信文の/definitions/message/part/@element 属性は、"ihe:Retrieve Form Response"として定義されねばならない。
⚫ 書式取得要求通信文の/definitions/portType/operation/input/@wsaw:Action 属性は、"urn:ihe:iti:2007:RetrieveForm"として定義されねばならない。
⚫ 書式取得応答通信文の/definitions/portType/operation/output/@wsaw:Action 属性は、
"urn:ihe:iti:2007:RetrieveFormResponse"として定義されねばならない。
⚫ /definitions/binding/operation/SOAP12:operation/@SOAPActionRequired 属性は"false"として定義されねばならない。
これらは SOAP 通信文のワイヤフォーマットに影響する要求事項である。その他の WSDL 属性は WSDL 内でのみ使用され、相互運用性に影響しない。要求と応答の完全なサンプルは 8.34.5.1 節 「SOAP 通信文の例」にある。
書式管理役の WSDL の情報提供と完全な RFD 型の XML 方式書類は IHE FTP サイトからオンラインで得られる。
Iftp://ftp.ihe.net/TF_Implementation_Material/をみよ。
8.34.5.1 SOAP 通信文の例
以 下 の 二 つ の 節 に SOAP 要 求 と そ の 関 連 SOAP 応 答 を 示 す 。通 信 文 例 は WS-Addressing ヘ ッ ダ <Action/>,<MessageID>,.;も示す。これら WS-Addressing ヘッダは ITI TF-2x: Appendix V 「IHE トランザクション用のウェブサービス」
に従って値が入れられている。短縮化のため、SOAP 通信文の本体の一部は省略されている。
8.34.5.1.1 書式取得 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:RetrieveForm</wsa:Action>___________________________________________________________________________________________________
29

データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________</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>

8.34.5.1.2 書式取得 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>___________________________________________________________________________________________________
30

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

8.35 書式提出[ITI-35]
この節は、IHE IT 基盤テクニカルフレームワークの ITI-35 トランザクションに対応する。ITI-35 トランザクションは書式記入役あるいは書式処理アクタに使用される。
8.35.1 範囲
このトランザクションは、書式記入役の書式管理役あるいは書式処理役への書式提出を含む。
8.35.2 使用例役割

アクタ：書式記入役
役割： 書式のデータ欄への入力完成を可能とする、書式表示と編集システム
アクタ：書式受領役
役割： 書式管理役が構成した書式から、提出された書式のデータを受け取るシステム。
アクタ：書式処理役
役割： 書式処理役の同じインスタンスで構成された書式から、提出された書式データを受け取るシステム。
8.35.3 参照規格
このトランザクションの実装者は ITI TF2x: Appendix V: Web Services for IHE Transactions に記載された全ての要求事項に適合せねばならない。

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___________________________________________________________________________________________________
31

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

8.35.4 相互作用図

8.35.4.1 書式提出
このトランザクションは書式記入役が書式事例のデータを、XML 書式で、書式受領役または書式処理役に提出するときに開始される。
8.35.4.1.1 トリガーイベント
書式提出トランザクションは、書式内からの提出動作により発動のきっかけを得る。
8.35.4.1.2 通信文の意味
書 式 提 出 ト ラ ン ザ ク シ ョ ン は 、 SubmitFormRequest 要 素 の XML 子 要 素 と し て 提 出 さ れ た 書 式 デ ー タ と 共 に 、SubmitFormRequest 要素を伝達しなければならない。内容プロファイルが SubmitFormRequest 要素の内容に追加の制限を課すことができる。
サポート資料（ftp://ftp.ihe.net/TF_Implementation_Material/）にあるスキーマをみよ。
8.35.4.1.3 期待される動作
書式提出要求を受け付けたら、書式受領役または書式処理役は SubmitFormResponse 要素、または、たとえば、提出されたデータが認識できないときは SOAP Fault を、それぞれ返さねばならない。
書式記入役は、書式受領役または書式処理役からの応答結果を表示できる。
書式受領役または書式処理役は、適切な場合には、表 3.35.4.1.3-1 に定める SOAP Faults を使用せねばならない。書式
記入役はここに記した以外の値を受け付けられねばならない。

エラーの説明提出されたデータを認識できない

表 8.35.4.1.3-1： SOAP Faults
コード
理由を示す文SenderRequired 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>___________________________________________________________________________________________________
32

データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________<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>

8.35.4.2 書式提出応答
8.35.4.2.1 トリガーイベント
この通信文は書式記入役の書式事例データの提出によりきっかけを得る。
8.35.4.2.2 通信文の意味
書式提出応答は以下を含む SubmitFormResponseType 要素を返さねばならない。
⚫ 内容プロファイルで制限されることのある responseCode 文字列⚫ RetrieveFormReponse で返された、FormData を含むオプションの内容要素⚫ 内容プロファイルで制限されることのあるオプションの contentType 文字列
サポート資料（ftp://ftp.ihe.net/TF_Implementation_Material/ ）にあるスキーマを見よ。

8.35.4.2.3 期待される動作
書式記入役は書式受領役または書式処理役からの応答結果を表示できる。書式の振る舞いは内容領域のプロファイル
でさらに制限されることがある。
8.35.5 プロトコル要求事項
このトランザクションの実装者は ITI TF-2x: Appendix V;: Web Services for IHE Transactions のすべての要求事項に適合せねばならない。
書式提出トランザクションは SOAP 1.2 を使用せねばならない。
WSDL 名前空間定義

これらは、RFD 提出書式 WSDL 定義に現れる順番に並べた、書式提出トランザクションの要求事項である。
⚫ 以下のデータ型が/definitions/types 節に読み込まれ（xds:import）ねばならない。
⚫ Namespace="urn:ihe:iti:rfd:2007", schema="RFD.xsd"⚫ 書式提出要求通信文の/definitions/message/part/@element 属性は、"ihe:SubmitFormRequest"として定義されねばならない。

___________________________________________________________________________________________________
33

データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________⚫
⚫

書式提出応答通信文の/definitions/message/part/@element 属性は、"ihe:SubmitFormResponse"として定義されねばならない。
追加の属性要求事項については、表 8.35.5-1 を参照すること。
表 8.35.5-1：追加の属性要求事項

これらは SOAP 通信文のワイヤフォーマットに影響する要求事項である。その他の WSDL 属性は WSDL 内でのみ使用され、相互運用性に影響しない。要求と応答の完全なサンプルは 8.35.5.1 節 「SOAP 通信文の例」にある。
サポート資料（ftp://ftp.ihe.net/TF_Implementation_Material/）を見よ。
<ihe:SubmitFormRequest>要素は、以下のように定義される：⚫ 一個以上の<xs:any>要素
これにより、書式管理役はいかなる XML 表現を使用する書式データでも提出書式を構成出来るようになる。
<ihe:SubmitFormResponse>要素は、以下のように定義される：
⚫
⚫

⚫
⚫

<ihe:formDataType>型の、書式取得応答にも使用される、オプションの<ihe:content>要素。もし存在すれば：
以下の一つを含まねばならない：⚫ XML で符号化された書式を含む、<ihe:Structured>⚫ base64binary encoding された書式を含む、<ihe:Unstructured>⚫ 書式の URL を含む、<ihe:URL>⚫ xs:string 型のオプションの<ihe:contentType>要素
xs:string 型のオプションの<ihe:contentType>要素
xs:string 型の必須の<ihe:responseCode>要素

8.35.5.1 SOAP 通信文の例
以 下 の 二 つ の 節 に SOAP 要 求 と そ の 関 連 SOAP 応 答 を示 す 。通 信 文 例 は WS-Addressing ヘ ッ ダ <Action/>,<MessageID>,.;も示す。これら WS-Addressing ヘッダは ITI TF-2x: Appendix V 「IHE トランザクション用のウェブサービス」
に従って値が入れられている。短縮化のため、SOAP 通信文の一部は省略されている。
8.35.5.1.1 書式提出 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>___________________________________________________________________________________________________
34

データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________<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><SubmitFormRequest xmlns="urn:ihe:iti:rfd:2007">…
</SubmitFormRequest></soap:Body></soap:Envelope>

8.35.5.1.2 書式提出 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: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></soup:Body></soup:Envelope>

8.35.6 安全の考慮
追加のプライバシと保護のため、必要に応じて終着点は自由に TLS を実装できる。内容プロファイルはデータの特質に応じて、ATNA の使用を要求することがある。

___________________________________________________________________________________________________
35

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

8.36 書式保存 [ITI-36]
この節は、IHE IT 基盤テクニカルフレームワークの ITI-36 トランザクションに対応する。ITI-36 トランザクションは書式記入
役と書式保管役に使用される。
8.36.1 範囲
このトランザクションは、書式記入役による書式事例(instance)の書式保管役への提出を含む。
8.36.2 使用例役割

アクタ：書式記入役
役割： 書式のデータ欄への入力完成を可能とする、書式表示と編集システム
アクタ：書式保管役
役割： 提出された書式を保管するシステム。
8.36.3 参照規格
このトランザクションの実装者は ITI TF2x: Appendix V: Web Services for IHE Transactions に記載された全ての要求事項に適合せねばならない。
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
8.36.4 相互作用図___________________________________________________________________________________________________
36

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

8.36.4.1 書式保管
このトランザクションは、保管目的での書式記入役による書式保管役へのデータ提出により開始される。
8.36.4.1 .1 トリガーイベント
書式記入役は、保管の目的で書式保管役にデータを提出するときはこのトランザクションを使用せねばならない。書類保管トランザクションは書式記入役が開始するか、書式内からの二次的提出動作がきっかけとなる。
8.36.4.1.2 通信文の意味
書類保存トランザクションは、ArchiveFormRequest 要素と、提出される書式のデータを ArchiveFormRequest 要素の XML子要素としたものとを、運ばねばならない。
サポート資料（ftp://ftp.ihe.net/TF_Implementation_Material/）にあるスキーマをみよ。
8.36.4.1.3 期待される動作
書式保存要求を受け付けたら、書式保管役は ArchiveFormResponse 要素、または、たとえば提出されたデータが認識できないときは、SOAP Faults を、それぞれ返さねばならない。
書式記入役は、書式受領役または書式保管役からの応答結果を表示できる。
書式保管役は、適切な場合には、表 8.36.4.1.3-1 に定める SOAP Faults を使用せねばならない。書式記入役はここに記した以外の値を受け付けられねばならない。
表 8.36.4.1.3-1： SOAP Faults
エラーの説明コード
理由を示す文SenderRequired 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>
8.36.4.2 書式保管応答___________________________________________________________________________________________________
37

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

8.36.4.2.1 トリガーイベント
この通信文は書式記入役による書式事例データの保管によりきっかけを得る。
8.36.4.2.2 通信文の意味
ArchiveFormResponse 要素は、以下を含む時に、返される。
⚫

内容プロファイルにより制限されることのある responseCode 文字列

サポート資料（ftp://ftp.ihe.net/TF_Implementation_Material/）にあるスキーマをみよ。
8.36.4.2.3 期待される動作
書式記入役は書式保管役からの応答を表示すことができる。書式の振る舞いは、内容領域のプロファイルによりさらに特徴付けられることがある。
8.36.5 プロトコル要求事項
書式保管要求と応答は、ITI TF-2x: Appendix V に定める要求事項に従って、同期ウェブサービス交換を使用して伝達されねばならない。
書式保管トランザクションは SOAP 1.2 を使用せねばならない。

ihe
soap12
wsaw
xsd

WDSL 名前空間定義
urn:ihe:iti:rfd:2007
http://schemas.xmlsoap.org/wsdl/soap12/
http://www.w3.org/2005/08/addressing
http://www.w3.org/2001/XMLSchema

これは、書式取得 WSDL 定義に現れる順番に並べた、書式保管トランザクションの要求事項である。
⚫ 以下のデータ型が/definitions/types 節に読み込まれ（xds:import）ねばならない。
⚫ Namespace="urn:ihe:iti:rfd:2007", schema="RFD.xsd"⚫ 書式保管要求通信文の/definitions/message/part/@element 属性は、"ihe:ArchiveFormRequest"として定義されねばならない。
⚫ 書式保管要求通信文の/definitions/message/part/@element 属性は、"ihe:ArchiveFormResponse"として定義されねばならない。
⚫ 追加の属性要求事項は表 3.36.5: 追加の属性要求事項を見ること。
表 8.36.5: 追加の属性要求事項___________________________________________________________________________________________________
38

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

これらは SOAP 通信文のワイヤフォーマットに影響する要求事項である。その他の WSDL 属性は WSDL 内でのみ使用され、相互運用性に影響しない。要求と応答の完全なサンプルは 8.36.5.1 節 「SOAP 通信文の例」にある。
WSDL の情報提供は ftp://ftp.ihe.net/TF_Implementation_Material/を見よ。
<ihe:ArchiveDrrmRequest>要素は、以下の様に定義される：⚫

一個以上の<xs:any>要素

これにより書式管理役は、いかなる XML 表現を使用した書式データも保管する書式を構成出来るようになる。
xs:string 型の<ihe:responseCode>要素は以下の様に定義される：⚫

必須の、xs:string 型の<ihe:responseCode>要素

8.36.5.1 SOAP 通信文の例
以下の二つの節の例に典型的な SOAP 要求とその関連 SOAP 応答を示す。通信文例は WS-Addressing ヘッダ<Action/>,<MessageID>,.;も示す。これら WS-Addressing ヘッダは ITI TF-2x: Appendix V: Web Services for IHE Transactions に従って値が入れられている。短縮化のため、SOAP 通信文の一部は省略されている。
8.36.5.1.1 書式保存 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>

8.36.5.1.2 書式保存 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:ArchiveFormResponse</wsa:Action></soap:Header><soap:Body><ArchiveResponse xmlns="urn:ihe:iti:rfd:2007"><responseCode />___________________________________________________________________________________________________
39

データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________</ArchiveFormResponse></soap:Body></soap:Envelope>

8.36.6 安全の考慮
本書 7.6.2 の緩和策の節に記す様に、追加のプライバシと保護のため、終着点は自由に必要に応じて TLS を実装できる。
内容プロファイルはデータの特質に応じて、ATNA の使用を要求することがある。

___________________________________________________________________________________________________
40

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

8.37 明確化情報取得（Retrieve Clarifications）[ITI-37]
この節は IHE ITI テクニカルフレームワークの ITI-37 に対応する。ITI-37 トランザクションは書式記入役、書式管理役ある
いは書式処理役に使用される。
8.37.1 範囲
このトランザクションには、書式管理役あるいは書式処理役から一組の明確化情報を要求する、書式記入役が含まれる。
明確化情報取得オプションを使用可能とする書式記入役はこの要求を、書式管理役、書式受領役、あるいは書式処理役が定めた、あるいは、合意した期間に基づいて、定期的に出さねばならない。すべての使用例がこのオプションを可能とするわけではないことに注意する。
書式記入役はこのトランザクション外の手段により取得した orgID を持っており、書式管理役あるいは書式処理役は、明確化せねばならないデータ、あるいは、書式取得トランザクションにより取得可能なその他の書式へのリンクの、いずれかを含む書式を戻す。すべての更新、明確化、新データは、書式提出トランザクションを用いて書式受取り役に提出される。
8.37.2 使用例役割

アクタ：書式記入役
役割：書式のデータ欄への入力完成を可能とする、書式表示と編集システム
アクタ：書式管理役
役割：特定の orgID を提供する要求に応じて、明確化のための情報を提供するシステム
アクタ：書式処理役
役割：特定の orgID を提供する要求に応じて、明確化のための情報を提供するシステム
8.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 Recommendation 20 October 2009. https://www.w3.org/TR/xforms11/
8.37.4 相互作用図___________________________________________________________________________________________________
41

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

8.37.4.1 明確化情報取得要求
明確化情報取得オプションが使用可能な書式記入役が、機関、あるいは、サイトに関係する明確化のための情報を取得する必要が生じた時に、このトランザクションが開始される。
8.37.4.1.1 トリガーイベント
明確化情報取得事象は、EHR（電子健康録）システム内で使用可能にすべき現行の明確化についての情報が必要となったことをきっかけに起生する。このトランザクションは、いつ明確化情報取得を始めるかは定めず、書式管理役あるいは書式処理役から明確化の情報を必要とするときに使用できる様にする事のみを定めている。このオプションを使用可能とし、これを周期的に実行するのは、書式記入役の責任である。
8.37.4.1.2 通信文の意味
このトランザクションの実装者は、ITI TF-2x: Appendix V: Web Services for IHE Transactions（「IHE トランザクション用のウェブサービス」）を参照すること。
以下のパラメータがこのトランザクションに定められている。
パラメータ名clarificationData

REQ
R

orgID
encodedResponseRR

archiveURL

R

context

R

説明明確化に特異的な値の xml 表
現

符号化された応答を返すかどうかを書式管理役に通知する
書式記入役が保存オプションを使用しているかどうかを書式管理役に通知する。
ワークフローコンテキストのXML 仕様値
この値は、適切に書式化された、以下の XML ドキュメントです。
組織を識別する文字列{true,false}
任意の書式記入役が識別する書式保存役の URL；ヌルでもよい
内容プロファイルで定義される；ヌルでもよい。

clarificationData は<content>要素のさらなる定義で、IHE 内容プロファイルにより拡張される。clarificationData 内容は最小で以下の通りである：___________________________________________________________________________________________________
42

データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________<clarificationData><orgID>a String identifying the form</orgID><encodedResponse>false</encodedResponse><archiveURL /><context/></clarificationData>
8.37.4.1.3 期待される動作
明確化情報取得情報を受け取ったら、書式管理役あるいは書式処理役は要求を構文解析し、RetrieveClarificationResponse 要素内に要求された応答を返すか、SOAP エラーを返さねばならない。
書式管理役あるいは書式処理役は書式、あるいは、URL を、a) encodedResponse; b) orgID; c) 追加の clarificationDataの値にもとづいて、返さねばならない。
明確化情報が手に入らないなら、明確化のための説明が無いことを示す書式で、情報がないことを示さねばならない。
encodedResponse が"true"なら、書式管理役、あるいは，書式処理役の応答は、構造化（XML）、あるいは、非構造化（non-XML）要素のいずれか一方でなければならない。
encodedResponse が"false"なら、書式管理役あるいは書式処理役の応答は、書式の取得と操作に直接ブラウザで使用できる URL 要素でなければならない。
orgID の値は書式管理役、あるいは、書式処理役により以前から割り付けられており、これは命名されたオプションの一つを識別する。書式管理役は複数の命名オプションを使用可能に出来るが、一個の orgID には一個の命名オプションしか使用可能でない。
書式管理役は、適切な場合には、表 3.37.4.1.3-1 に定める SOAP Faults を使用せねばならない。書式記入役はここに定める値を超える値を受け取れねばならない。
表 8.37.4.1.3-1：SOAP Faults
エラーの説明コード
理由を示す文SenderRequired Information MissingorgID が無いなど、情報が欠損している
SenderUnknown orgID
書式が存在しない
SOAP Fault の例は以下である：___________________________________________________________________________________________________
43

データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________<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></env:Reason></env:Fault></env:Body></env:Envelope>

書式管理役あるいは書式処理役が割り付けた orgID は、命名された書式オプションの一つを使用する。書式管理役ある
いは書式処理役は複数の命名オプションを使用可能だが、一個の orgID には一個の命名オプションしか使用可能でない。
8.37.4.1.4 安全の考慮
明確化情報取得要求通信文の安全考慮は、書式取得要求通信文となんらかわらない: 8.34.4.1.4 節を見ること。
8.37.4.2 明確化要求応答
8.37.4.2.1 トリガーイベント
明確化情報取得トランザクションで提供された orgID にもとづいて、書式を提供する書式管理役あるいは書式処理役が、書式配達（Deliverry of a Form）のきっかけになる。
8.37.4.2.2 通信文の意味
明確化情報取得に応答して、書式あるいは URL が返される。
8.37.4.2.3 期待される動作
書式記入役は書式を表示したり、書式を取得するため返された URL へ導いたりする。
8.37.4.2.3.1 XHTML 取扱
書式管理役あるいは書式処理役は、応答として返された書式であれ、返された URL に参照された書式であれ、W3C
HTML1.0 推奨の付録 C にある、XHTML 基礎および、W3C HTML 適合性ガイドラインを使用して書式化された書式を返さねばならない。返された書式では提出と全ての必須の保存トランザクションを使用可能とせねばならない。
8.37.4.2.3.2 XForm オプション
XForm オプションを使用可能とする書式管理役あるいは書式処理役は、応答として返された書式であれ、返された URLに参照された書式であれ、XForm 1.1 に適合するような書式を返す能力を追加して持たねばならない。XHTML Basic お
よび、W3C XHTML 1.0 Recommendation の付録 C に記載された W3C 適合性ガイドラインに従って、XForm の親言語は___________________________________________________________________________________________________
44

データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________XHTML Basic でなければならない。返された書式では提出と全ての必須の保存トランザクションを使用可能とせねばならない。
8.37.5 プロトコル要求事項
明確化情報取得要求とその応答は、ITI TF-2x: Appendix V に定められた要求事項に従って、同期ウェブサービス交換を用いて伝達されねばならない。
明確化情報取得要求は SOAP 1.2 を使用せねばならない。

ihe
soap12
wsaw
xsd

WSDL 名前空間定義
urn:ihe:iti:rfd:2007
http://schemas.xmlsoap.org/wsdl/soap12/
http://www.w3.org/2005/08/addressing
http://www.w3.org/2001/XMLSchema

以下は、WSDL 定義に現れる順番に並べた、明確化情報取得トランザクションの要求事項である。
⚫ 以下のデータ型が/definitions/types 節に読み込まれ（xds:import）ねばならない。
⚫ Namespace="urn:ihe:iti:rfd:2007", schema="RFD.xsd"⚫ 明確化情報取得通信文の/definitions/message/part/@element 属性は、"ihe:RetrieveClarificationRequest"
として定義されねばならない。
⚫ 明 確 化 情 報 応 答 通 信 文 の /definitions/message/part/@element 属 性 は 、"ihe:RetrieveClarificationResponse"として定義されねばならない。
⚫ 明確化情報要求通信文の/definitions/portType/operation/input/@wsaw:Action 属性は、
"urn:ihe:iti:2007:RetrieveClarification"として定義されねばならない。
⚫ 明確化情報応答通信文の/definitions/portType/operation/output/@wsaw:Action 属性は、
"urn:ihe:iti:2007:RetrieveClarificationResponse"として定義されねばならない。
⚫ /definitions/binding/operation/SOAP12:operation/@SOAPActionRequired 属性は"false"として定義されねばならない。
これらは SOAP 通信文のワイヤフォーマットに影響する要求事項である。その他の WSDL 属性は WSDL 内でのみ使用され、相互運用性に影響しない。要求と応答の完全なサンプルは 8.4.5.1 節 「SOAP 通信文の例」にある。
書式管理役の WSDL の情報提供は Ftp://ftp.ihe.net/TF_Implementation_Material/ITI/以下を見ること。RFD データ型のXML 方式書類は IHE FTP サイトからオンラインで得られる。ftp://ftp.ihe.net/TF_Implementation_Material/を見ること。
8.37.5.1 SOAP 通信文の例
以 下 の 二 つ の 節 に SOAP 要 求 と そ の 関 連 SOAP 応 答 を 示 す 。通 信 文 例 は WS-Addressing ヘ ッ ダ <Action/>,<MessageID>,.;も示す。これら WS-Addressing ヘッダは ITI TF-2x: Appendix X 「IHE トランザクション用のウェブサービス」
に従って値が入れられている。短縮化のため、SOAP 通信文の一部は省略されている。
8.37.5.1.1 明確化情報取得 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>___________________________________________________________________________________________________
45

データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________<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><encodedResponse>false</encodedResponse><archiveURL /><context /></clarificationData></RetrieveClarificationsRequest></soap:Body></soap:Envelope>
8.37.5.1.2 明確化情報取得 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> 3025</form><contentType /><responseCode /></RetrieveClarificationsResponse></soap:Body></soap:Envelope>___________________________________________________________________________________________________
46

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

付録 A
A.1

RFD 実装上の留意点

データ収集用紙の留意点

A.1.1 収集データ項目の名称、語彙収集すべきデータの項目は RFD では定めず、データ収集組織がデータ収集の目的、予定する解析や分析結果の将来の使用、将来の拡張などを考慮して決定する。RFD の枠組みを用いて、データ収集用紙の取得、記入、提出を行う際には、データ収集組織は収集すべきデータの項目名に標準に定められた名称を使用すべきである。さらに、データ収集組
織が、データ収集用紙に必要な標準に似た内容の複数の標準がある場合には、使用する標準について我が国で統一した選択を行っておくことが勧められる。同じ項目が別の標準により異なって命名されている可能性があるため、単に「標準を使用する」では十分といえない。
用紙を受け取る電子カルテなどのシステムでは標準とは異なったデータ項目名が使用されることがある。データ収集用紙に使用される標準が上記のように一律に定まっていれば、このようなシステムを用いる組織でも、「対応つけ表」を一つ用意すれば種々の組織が提供する複数のデータ収集用紙への対応が容易になると期待される。
データ収集後の解析を容易にし、曖昧さの少ないものとするには、語彙の標準化と用語使用の適切な規則や制限が上記に加えて、必要である。数値データは語彙の標準化と用語の使用規則・制限には無縁であるが、数値を正しく解釈し比較できるようにするには、単位、測定法、正常域、検出感度、その方法での測定値の分布型とこれを定めるパラメータ、例えば正規分布では、平均、標準偏差、などが数値と共に提供されねばならない。
A.1.2 収集データ項目の一例
収集データ項目とその名称の例示を行う目的は、RFDに基づいて種々の領域でデータ収集や登録を行おうとする
実装者に対して、RFDの概念をより具体的に示し、RFDの普及を推進するためである。
感染症の届け出については厚生労働省が届けるべき疾患、届出様式（本規格で「書式」に該当）を定めており（https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/kenkou_iryou/kenkou/kekkaku-kansenshou/kekkaku-k
ansenshou11/01.html#h2_free4）、データ項目とその名称を改めて定める必要がない。同様に、医薬品医療機器法に基づく副作用・感染症・不具合報告（http://www.pmda.go.jp/safety/reports/hcp/pmd-act/0002.html）、など国が定める届け出については、データ項目とその名称を改めて定める必要がなく、ここでの例示には使用しない。学術団体等が行うデータ収集は、主宰する団体が調査・登録の目的に応じで自ら作成するものであり、標準的データ項目や標準的語彙の例示対象とはなりにくい。
以上を考慮して、ここでは医師による癌登録への報告を取り上げる。IHE 医療の質・研究・公衆衛生領域（Quality,
Research and Public Health (QRPH)）は、大枠としての RFD の上に、癌登録に必要な、より詳細な標準使用法の制限を課し、医師公衆衛生データ保管庫報告－がん登録（Physician Reporting to a Public Health Repository – Cancer Registry,
PRPH-Ca）統合プロファイル（試験実装版）を定めている。（詳細はhttps://www.ihe.net/Technical_Framework/upload/IHE_QRPH_Suppl_PRPH_Ca_Rev2-1_2011-09-02.pdf をみよ）。この統
合プロファイルは本規格の[ITI-34]と[ITI-35]トランザクションを使用しており、RFD の特定領域への一適用例である。この統合プロファイルは試験実装でコネクタソン（接続試験）にすでに供されており、合格した実装がある。
PRPH – Ca 統合プロファイルで使用するデータ項目を以下の表 A.1.2-1: データ項目に示す。
表 A.1.2-1: データ項目

Date Case Report Exported

Data Element
データ項目
症例報告提出日___________________________________________________________________________________________________
47

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

Patient Name (First, Middle, Last)
Patient Street Address (City, State, Zip
Code, Country)
Address History
Patient Telephone
Patient Sex/Gender
Patient Date of Birth

患者氏名
患者住所

Patient Medical Record Number

患者カルテ番号

Patient Social Security Number

患者社会保障番号

Patient Race

患者人種

Patient Ethnicity
Patient Birth Place(City, State, Country)
Patient Marital Status

患者民族

Physician Name

医師氏名

Physician Address

医師住所

Provider Organization (Name and ID)

医療機関

Provider Referred From

紹介元施設

Coded Social History Section

符号化社会歴セクション

Social History Narrative

自由記載社会歴

Occupation

職業

Industry

産業

History of Tobacco Use

喫煙歴

Payers Section

支払者セクション

Primary Payer at Diagnosis

診断時の主たる支払者

Cancer Diagnosis Section

がん診断セクション

Cancer Diagnosis Entry

がん診断

Diagnosis Date

診断日Histology

組織形

Behavior
Best Method of Confirmation(Diagnostic confirmation)
Primary Site

ふるまい

Laterality

左右別Stage Group Narrative

自由記載ステージ群

TNM Clinical Stage GroupTNM 臨床病期

TNM Clinical Stage Descriptor

TNM 臨床病期記述子

TNM Edition

TNM 版数TNM Clinical Staged By

TNM 臨床病期決定手段

TNM Clinical T

TNM 臨床 T 因子

TNM Clinical N

TNM 臨床 N 因子

TNM Clinical M

TNM 臨床 M 因子

Active Problems Section

現行診断セクション

Comorbidities

合併症

Progress Note Section

経過記載セクション

住所履歴
患者電話番号
患者性別
患者番号

患者生誕地
患者婚姻状態確定診断方法原発巣___________________________________________________________________________________________________
48

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

Progress Notes Narrative

経過自由記載Coded Results Section

符号化結果セクション

Procedure

検査

Procedure Date

検査日

Coded Result

符号化結果

Result Text

自由記載結果Result Date

結果判定日

Diagnosing Laboratory

診断臨床検査Procedures Section
Procedure (e.g., Surgery of primarysite)
Date of Surgery

手技セクション

Medications Section

治療薬セクション

Medications

治療薬

Chemotherapy, Hormone Therapy,
Immunotherapy
Start Date

化学療法、ホルモン療法、免疫療法
開始日

Stop Date

終了日

Frequency

頻度

Route

投与経路

Dose

量

Site

部位

Rate

速度

Product

製品

Strength

力価

Code

コード

Instructions
Medications Administered Section(medications that are administeredduring the encounter)
Chemotherapy, Hormone Therapy,
Immunotherapy

指示

手技（原発巣の手術）
手術日投与済治療薬セクション（受診中の治療薬）

Medications

化学療法、ホルモン療法、免疫療法
治療薬

Start Date

開始日

Stop Date

終了日

Frequency

頻度

Route

経路

Dose

量

Site

部位

Rate

速度

Product

製品

Strength

力価

Code

コード

Instructions

指示

Care Plan Section

ケアプランセクション___________________________________________________________________________________________________
49

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

Observation Requests

観察要求

Medication

治療薬

Procedure

手技

Patient Referred To (Encounter)

紹介先（受診）A.2 我が国での RFD 実装例
6.1.4 節「我が国での薬剤副作用調査例」に記載した実装についての詳細を以下に記す。この事例はある特定の経口糖尿病薬の市販後調査のために整備されたものである。
⚫ 電子カルテの使用者が副作用報告を行うよう指示すると、このために電子カルテ内に整備されたア
プリケーションは電子カルテ上でデータ入力を支援する書式を生成する。必要なデータ項目の一部
は、SS-MIX 標準化ストレージから読みだされ、自動的にデータが入力され、使用者に提示される。
使用者はここで必要な追加入力を行える。使用者が記入を完了したと指定すると、データは電子症例報告書（electronic case report form）として電子媒体に書き出される。
⚫ 作成された媒体はインターネット接続している機器に手動で接続され、製薬会社の保持するサーバ、
すなわち、書式受領役に書式提出トランザクション[ITI-35]により送信される。
表 A.2-1

薬剤有害事象報告（経口糖尿病薬市販後調査の例）

項目

適用

Prepop対応*

患者基本情報患者 ID

適宜匿名化することが必須。

n姓

イニシャル。"*"も可n

名

イニシャル。"*"も可n

性別

二択（男、女）

n

妊娠状態

女性のみ

n

生年月
年齢

生年月、年齢のいずれか一方で可

n
n

患者背景
糖尿病罹病期間年月で記載。「不明」入力可

n

入外区分

使用開始時の区分を記入と指定n

身長

単位は cm。「不明」入力可n

体重

単位は kｇ。「不明」入力可

n

喫煙習慣

四択（吸わない、吸う、吸っていたがやめた、不明）

n

飲酒習慣

三択（あり、なし、不明）

nアレルギーの有無

三択（あり、なし、不明）

nアレルギー原因物質

アレルギー「あり」の場合に記入

n症状

アレルギー「あり」の場合に記入

n

糖尿病前治療（食事療法）
糖尿病前治療（食事療法）詳
細糖尿病前治療（運動療法）
糖尿病前治療（運動療法）詳
細既往症・合併症

三択（あり、なし、不明）

n

糖尿病前治療（食事療法）「あり」の場合に記入

n

三択（あり、なし、不明）

n

糖尿病前治療（運動療法）「あり」の場合に記入

n___________________________________________________________________________________________________
50

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

既往症・合併症の有無

二択（あり、なし）

n

高血圧症

二択（合併症、既往症）

n

悪性腫瘍

二択（合併症、既往症）

n

心・脳血管性疾患

二択（合併症、既往症）

n

脂質異常症

二択（合併症、既往症）

n

痛風

二択（合併症、既往症）

n

高尿酸血症

二択（合併症、既往症）

n

その他疾患

必要な数だけ列挙しそれぞれに既往症・合併症を区別

n

腎疾患の有無二択（あり、なし）

n

腎疾患詳細

必要な数だけ列挙しそれぞれに既往症・合併症を区別

n

肝疾患の有無二択（あり、なし）

n

肝疾患詳細

必要な数だけ列挙しそれぞれに既往症・合併症を区別

n糖尿病合併症の有無

二択（あり、なし）

n

神経障害

糖尿病合併症「あり」の場合に、既往症・合併症を区別

n腎症

糖尿病合併症「あり」の場合に、既往症・合併症を区別

n

網膜症

糖尿病合併症「あり」の場合に、既往症・合併症を区別

n

使用理由

二択（2 型糖尿病、その他）

n

その他の使用理由詳細

使用理由「その他」の場合に記載

n

一日投与量

mg 数と回数を入力

n投与開始年月日

年月日を入力y投与終了年月日

日付入力するか、「継続中」を選択

n

変更

n

変更理由詳細二択（投与内容変更、中止）
七択（改善、効果不十分、初回以降来院なし、転院・調査途中から来院なし、有害事象、患者希望、その他）「その他」選択の場合に記入

併用薬の有無二択（あり、なし）

n

併用薬

薬品名を入力n併用薬投与経路

四択（経口、注射、概要、その他）

n

その他併用薬投与経路の詳細「その他」選択の場合に記入

n併用薬一日投与量量の数値、単位を入力

n

併用薬用法

二択（適量、頓服）

n

薬品の投与状況

変更理由nn

併用薬一日投与回数n併用薬投与開始年月日

n併用薬投与終了年月日

年月日を入力、または「継続中」選択n

併用療法（薬剤以外）

三択（あり、なし、不明）

yその他の療養詳細「その他」選択の場合に記入

n併用療法（薬剤以外）開始日

y併用療法（薬剤以外）終了日

y

臨床経過

（投与前、3 か月後、6 か月後、9 か月後、12 か月後、中止時の値を記載）

バイタルサイン
収縮期血圧（mmHg）

y___________________________________________________________________________________________________
51

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

拡張期血圧（mmHg）

y

脈拍（回/分）y

体重（kg）y

糖尿病関連検査HbA1ｃ（％）

y

空腹時血糖(mg/dl)y

随時血糖(mg/dl)y

尿検査
尿ケトン体（定性）y

尿アルブミン（定性）y尿クレアチニン（定性）y

尿蛋白（定性）

y

臨床検査
赤血球

y

白血球

y

血清クレアチニン（mg/dl）y

BUN（mg/dl）y

AST(U/L)y

ALT(U/L)yγGTP(U/L)y

ALP(U/L)y

総ビリルビン（mg/dl）y

総コレステロール（mg/dl）y

HDL-コレステロール（mg/dl）y

LDL-コレステロール（mg/dl）

y

トリグリセライド（mg/dl）y

有害事象
有害事象発現の有無

二択（あり、なし）n

重篤性

二択（非重篤、重篤）
六択、複数選択可（死亡、生命を脅かすもの、入院/入院期間の延長、永続的な障害・機能不全に陥るもの、先天異常をきたすもの、その他の医学的に重要な状態）

y

調査対象薬品に対する処置

五択（継続、減量、休薬/中止、中止後発現、不明）

y

対症療法

三択（あり、なし、不明）

y

重篤有害事象詳細n

有害事象に対する処置

転帰年月日
転帰

y
六択（回復、軽快、未回復、後遺症あり、本事象による死亡、不明）

y

後遺症の詳細n

転帰不明の理由n

調査対象薬との因果関係

五択（確実、疑われる、否定できない、なし、不明）y*事前に自動入力が可能（y）か否か（n）を示す。

___________________________________________________________________________________________________
52

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

A.3 実装に適用可能なその他の統合プロファイル
国際 IHE では RFD を基礎に特定用途に適合させた統合プロファイルを提案している。
A.3.1 IHE 医療の質・研究・公衆衛生領域（Quality, Research and Public Health (QRPH)）の臨床研究書類（ClinicalResearch Document, CRD）
この統合プロファイルは、CDA 標準に基づいて作成された電子診療録データから臨床研究書類を生成する標準的方法を定めている。RFD で定めた枠組みを使用し、書式取得トランザクション[ITI-34]の prepopData とWorkflowData をさらに詳細に定め、データ収集用紙に既知のデータをあらかじめ記入する機能を最適化している。詳細は、https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_TF_Vol_1.pdf をみよ。
A.3.2 IHE 医療の質・研究・公衆衛生領域（Quality, Research and Public Health (QRPH)）の薬剤安全性報告（Drug Safety Content, DSC）
この統合プロファイルは、CDA 標準に基づいて作成された電子診療録データから副作用書類を生成する標準的方 法 を 定 め て い る 。 RFD の 枠 組 み を 使 用 し て 、 書 式 取 得 ト ラ ン ザ ク シ ョ ン [ITI-34] の prepopData とWorkflowData をさらに詳細に定めている。通信の安全のために、IHE ITI 領域の ATNA, CT, XUA 統合プロフ
ァイルを同時に使用する方法を定めている。
詳細は、https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_TF_Vol_1.pdf をみよ。

___________________________________________________________________________________________________
53

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

付録 B

監査通信文の例

本規格では情報セキュリティの確保については、別に開発されたIHE統合プロファイル、すなわち、監査証跡とノード認証（ATNA）プロファイル、ATNAが依存する時刻同期プロファイル（CT）、施設間使用者確認プロファイル（XUA）、などを必要に応じて使用するとしている。
RFDのトランザクションに定める監査通信文を以下に表で示す。
表にEvent（事象）とかかれた枠の右側に並ぶ項目が、監査通信文での事象についての監査通信文の識別情報となる。“Event”枠の下方の行にあるアクタ等は監査すべき対象を示す。「ここに」以下の表の左欄で示されるアク
タ等について、同じ表の左から二番目の項目にあるデータが監査通信文に記録される。
表のOpt欄は以下を示す。
⚫ M このデータは必須である⚫ U このデータのオプション性は指定されていない⚫ C このデータは、ある条件が真実なら必須である

B.1 書式取得（Retrieve Form）[ITI-34] 監査通信文
書式取得トランザクションは、ITI TF-2a: 表 3.20.4.1.1.1-1 に定めるように、PHI-export 事象のことがあります。このトランザクションを監査するアクタは、以下の例外を除いて、DICOM “Data Export”/”Data Import”に適合する監査データを生成せねばなりません。
B.1.1 書式記入役監査通信文：

ここに、___________________________________________________________________________________________________
54データ入力用書式取得・提出に関する仕様___________________________________________________________________________________________________________________________________________________________________________________________________________
55

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

B.1.2 書式管理役監査通信文：

ここに、___________________________________________________________________________________________________
56

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

B.1.3 書式処理役監査通信文：

ここに、___________________________________________________________________________________________________
57

データ入力用書式取得・提出に関する仕様___________________________________________________________________________________________________________________________________________________________________________________________________________
58

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

B.2 書式提出（Submit Form）[ITI-35] 監査通信文
書式提出トランザクションは、ITI TF-2a: 表 3.20.4.1.1.1-1 に定めるように、PHI-export 事象のことがあります。このトランザクションを監査するアクタは、以下の例外を除いて、DICOM “Data Export”/”Data Import”に適合する監査データを生成せねばなりません。
B.2.1 書式記入役監査通信文：

ここに、___________________________________________________________________________________________________
59

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

B.2.2 書式受領役監査通信文：

ここに、___________________________________________________________________________________________________
60

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

B.2.3 書式処理役監査通信文：

ここに、___________________________________________________________________________________________________
61

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

B.3 書式保存（Archive Form）[ITI-36] 監査通信文
書式保存トランザクションは、ITI TF-2a: 表 3.20.4.1.1.1-1 に定めるように、PHI-export 事象のことがあります。このトランザクションを監査するアクタは、以下の例外を除いて、DICOM “Data Export”/”Data Import”に適合する監査データを生成せねばなりません。

___________________________________________________________________________________________________
62

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

B.3.1 書式記入役監査通信文：___________________________________________________________________________________________________
63データ入力用書式取得・提出に関する仕様________________________________________________________________________________________________________

B.3.2 書式保存監査通信文：

ここに、___________________________________________________________________________________________________
64

データ入力用書式取得・提出に関する仕様___________________________________________________________________________________________________________________________________________________________________________________________________________
65