地域医療連携情報システム構築ハンドブック 201１ 附属書「地域医療連携情報システム構築ハンドブック 2011」
附属書(参考・解説)―IHE XDS による HIE（Health Information Exchange）の構築―

2011 年 12 月

ePHDS 委員会/日本 PACS 研究会

日本 IHE 協会編

地域医療連携情報システム構築ハンドブック 201１ 附属書

目次
附属書 A. XDS の利用場面（画像連携の場合） ................................................. 6
A.1 構築するシステムのユースケース ........................................................... 6
A.2 システム構成例 ................................................................................... 7
A.3 システムと利用する統合プロファイル／アクタ ........................................... 8
A.4 仕様書記載ポイント（例）....................................................................... 8
附属書 B. XDS 概説 .................................................................................... 12
B.1 XDS のアクタとトランザクション .............................................................. 12
B.2 XDS における処理の流れ .................................................................... 14
B.3 メタデータの種類................................................................................ 17
B.4 トランザクションの通信方式 .................................................................. 28
B.5 各アクタの設置形態 ............................................................................ 38
B.6 各アクタが持つべき機能 ...................................................................... 39
B.6.1 ドキュメントソース .......................................................................... 39
B.6.2 ドキュメントリポジトリ ...................................................................... 40
B.6.3 ドキュメントレジストリ ...................................................................... 42
B.6.4 ドキュメントコンシューマ ................................................................. 46
B.7 XDS における最近の動向 .................................................................... 47
B.7.1 オンデマンドドキュメントソース ........................................................ 48
B.7.2 ドキュメントアドミニストレータ ........................................................... 49
B.7.3 非同期型 Web サービス交換 .......................................................... 49
B.7.4 統合プロファイル MPQ .................................................................. 50
附属書 C. PIX/PDQ 概説............................................................................. 51
C.1 はじめに ........................................................................................... 51
C.2 ユースケース（シナリオ） ...................................................................... 51
C.3 PIX/PDQ 統合プロファイルの概要 ........................................................ 52
C.4 PIX .................................................................................................. 55
C.4.1 アクタとトランザクション .................................................................. 55
C.4.2 オプション ................................................................................... 56
C.4.3 プロセスフロー ............................................................................. 57
C.4.4 eMPI との関係 ............................................................................. 58
C.5 PDQ ................................................................................................. 59
C.5.1 アクタとトランザクション .................................................................. 59
C.5.2 オプション ................................................................................... 60
附属書 D. ATNA, CT 概説 ........................................................................... 61
D.1 セキュリティ基盤概要 .......................................................................... 61
D.2 統合プロファイル各論 ......................................................................... 61
D.2.1 ATNA ......................................................................................... 61
D.2.2 CT ............................................................................................. 64

地域医療連携情報システム構築ハンドブック 201１ 附属書D.3 監査証跡の要求仕様書記載のポイント .................................................. 64
D.3.1 監査証跡ログを記載するイベントの抽出方法 .................................... 64
D.3.2 監査証跡ログイベントの例 ............................................................. 67
D.3.3 監査証跡ログに記載すべきこと ...................................................... 68
D.4 監査ログ関連の仕様書記載例 ............................................................. 68
D.5 監査証跡ログの例 .............................................................................. 68
D.5.1 監査証跡ログのユースケース ......................................................... 68
D.5.2 監査証跡ログの出力形式 .............................................................. 69
D.5.3 監査証跡ログのスキーマ ............................................................... 75
附属書 E. XCA 概説 .................................................................................... 85
E.1 アクタとトランザクション ........................................................................ 85
E.1.1 XCA アクタ .................................................................................. 86
E.1.1.1 ドキュメント利用者（Document Consumer） ...................................... 86
E.1.1.2 開始ゲートウェイ（Initiating Gateway） ............................................ 86
E.1.1.3 応答ゲートウェイ（Responding Gateway） ........................................ 86
E.1.2 XCA トランザクション ..................................................................... 86
E.1.2.1 Cross Gateway Query[ITI-38] トランザクション ............................... 86
E.1.2.2 Cross Gateway Retrieve[ITI-39]トランザクション.............................. 87
E.2 トランザクションのオプションとアクタのグループ化 .................................... 87
E.3 homeCommunityId .............................................................................. 88
E.4 シナリオ例 ......................................................................................... 88
E.5 セキュリティ要求事項 .......................................................................... 91
E.6 NAV との関連 .................................................................................... 92
E.7 XDS の構造を持たないコミュニティとの連携 ............................................ 92
E.7.1 XAD 間の連携例 .......................................................................... 92
E.7.2 nonXDS コミュニティとの連携 .......................................................... 92
E.7.3 XDS コミュニティの集合体である場合の連携 ..................................... 93
E.7.4 nonXDS コミュニティの集合体である場合の連携 ................................ 93
E.7.5 透明な XAD である場合の連携 ...................................................... 93
附属書 F. XCA-I 概説 ................................................................................. 96
F.1 統合プロファイルの依存関係................................................................ 96
F.2 XCA-I アクタとトランザクション ............................................................. 96
F.2.1 XCA-I アクタ ............................................................................... 96
F.2.1.1 開始画像ゲートウェイ（Initiating Imaging Gateway）.......................... 97
F.2.1.2 応答画像ゲートウェイ（Responding Imaging Gateway） ...................... 97
F.2.2 XCA-I トランザクション .................................................................. 97
F.2.2.1 Cross Gateway Retrieve Imaging Document Set[RAD-75] ................ 97
F.2.2.2 Retrieve Imaging Document Set[RAD-69] ...................................... 97
F.2.2.3 XCA-I オプション....................................................................... 98
F.3 ユースケース ..................................................................................... 99
F.4 セキュリティ要求事項 ........................................................................ 101
附属書 G. XCPD 概説 ............................................................................... 103

地域医療連携情報システム構築ハンドブック 201１ 附属書

G.1 アクタとトランザクション ...................................................................... 103
G.1.1 アクタ ....................................................................................... 103
G.1.2 トランザクション .......................................................................... 104
G.1.3 オプション ................................................................................. 105
G.1.4 参照する標準・仕様類 ................................................................ 106
G.2 XCPD における処理の流れ ............................................................... 106
G.2.1 シナリオ１・Peer-to-Peer ............................................................. 107
G.2.2 シナリオ２・ヘルスデータロケータの使用 ........................................ 109
附属書 H. XDR 概説 ................................................................................. 113
H.1 アクタとトランザクション ...................................................................... 113
H.1.1 アクタ ....................................................................................... 113
H.1.2 トランザクション .......................................................................... 113
H.1.3 オプション ................................................................................. 114
H.2 XDR における処理の流れ ................................................................. 114
H.2.1 シナリオ１ .................................................................................. 114
H.2.2 シナリオ２ .................................................................................. 114
H.2.3 シナリオ３ .................................................................................. 114
H.2.4 シナリオ４ .................................................................................. 115
附属書 I. XDM 概説 .................................................................................. 116
I.1 アクタとトランザクション ....................................................................... 116
I.1.2 オプション................................................................................... 116
I.2 XDM における処理の流れ .................................................................. 118
附属書 J. オープンソースの利用方法 ........................................................... 120
J.1 概要 ................................................................................................ 120
J.2 スキーマファイル ............................................................................... 120
J.3 NIST XDS レジストリ・リポジトリ ............................................................ 121
J.3.1 概要 .......................................................................................... 121
J.3.2 あらかじめ必要となるツール .......................................................... 122
J.3.3 ダウンロード及びインストール ........................................................ 123
J.3.4 その他の機能 ............................................................................. 123
J.3.5 Public Registry ............................................................................ 127
J.4 XDS ツールキット............................................................................... 128
J.4.1 概要 .......................................................................................... 128
J.4.2 あらかじめ必要となるツール .......................................................... 128
J.4.3 ダウンロード及びインストール ........................................................ 128
J.4.4 テストに関する情報 ..................................................................... 129
J.5 他のオープンソース ........................................................................... 132
J.5.1 OpenHealthTools が公開するオープンソース .................................. 132
J.5.2 CodePlex ................................................................................... 132
J.5.3 NHIN CONNECT ........................................................................ 132
J.5.4 Omar ......................................................................................... 133
附属書 K. IHE ポリシーTemplate など........................................................... 134

地域医療連携情報システム構築ハンドブック 201１ 附属書K.1 医療連携コミュニティの構築 ............................................................... 134
K.2 IHE IT Infrastructure Technical Framework .......................................... 141
附属書 L. 提案依頼事項について ............................................................... 147

地域医療連携情報システム構築ハンドブック 201１ 附属書

執筆者一覧
・第 1 章安藤 裕

放射線医学総合研究所 重粒子医科学センター病院

・第 2 章、第 3 章、附属書 E、附属書 F
細羽 実
京都医療科学大学
・第 3 章、附属書 C
大林 正晴 株式会社 管理工学研究所
・第 4 章山本 裕

横河医療ソリューションズ 株式会社・第 5 章、附属書 I、附属書 L
谷川 琢海 旭川医科大学病院 経営企画部
・第 6 章、附属書 K
野津 勤
財団法人 理工学振興会
・第 7 章喜多 紘一

一般社団法人 保健医療福祉情報安全管理適合性評価協会

・第 3 章、附属書 A、附属書 D、附属書 H
向井まさみ 放射線医学総合研究所 重粒子医科学センター病院 医療情報課
・第 3 章、附属書 B、附属書 G、附属書 J
高橋 正人 株式会社 管理工学研究所
・編集
森口 修逸

株式会社 エム・ピー・オー

地域医療連携情報システム構築ハンドブック 201１ 附属書

附属書 A.

XDS の利用場面（画像連携の場合）本附属書では、IHE XDS の利用場面として画像連携の場合のシステム構築で考慮すべきことを具体例で説明する。
本編の第 7 章でも述べたように、４疾病（がん対策、脳卒中対策、急性心筋梗塞対策、糖尿病対策）及び 5 事業（救急医療、災害時医療、へき地医療、周産期医療、小児医
療）に対する医療計画では、地域医療連携が不可欠となっている。また、医療設備の高度化にともない広域で遠隔地にある施設間の連携の必要性も高まっている。ここでは、放射線医学総合研究所（放医研）におけるがん治療での画像情報を中心にした施
設間情報連携の事例を取り上げる。
A.1 構築するシステムのユースケース「重粒子治療紹介システム」の構築する場合のユースケースを検討してみる。
1) 患者は、具合が悪くなり近医の医療機関 A を受診。結果悪性腫瘍の診断がくだされる。担当医は治療法を挙げて、患者は重粒子治療を選択する。担当医
は重粒子治療専門病院に相談することとする。
2) 担当医は、重粒子治療コンサルテーションシステムにアクセスし、コンサルテーション依頼を行う。
3) 放医研相談窓口はコンサルテーション依頼を見て適切な医師に割り振る。
4) 以前のコンサルテーション情報を確認し、同じ患者の履歴があれば同一患者の治療として登録/設定を行う。
5) 医師はコンサルテーション内容（病歴および画像情報）を確認し、治療可否を回答する。同じ患者が過去にコンサルテーション／治療を受けている場合は、同時に過去のコンサルテーション情報／治療情報も参照する。
6) 医療機関 A の担当医は回答を確認し患者に伝える。
7) 重粒子治療可となった場合、患者は紹介状をもって重粒子治療専門病院を受診する。
8) 重粒子治療専門病院では、既存のコンサルテーション内容をふまえ初診を行う。
9) 初診後、重粒子治療専門病院の担当医師は紹介元医師に紹介お礼とともに治療計画や事前の依頼事項を伝える。
10) 患者は重粒子治療専門病院で治療を受ける。
11) 重粒子治療専門病院担当医師は、治療終了後、フォローアップを依頼する施設（紹介元施設とは限らない）へフォロー依頼を行う。依頼時には、治療前6地域医療連携情報システム構築ハンドブック 201１ 附属書の病歴、治療実施情報、治療前検査画像、治療後検査画像等が提供される。
12) フォロー担当医は定期的に患者の状態をチェックし（患者の受診による）、フォローアップ報告を行う。
13) 再発/転移が認められた場合は、再度、重粒子治療の適応を検討する。
A.2 システム構成例
ユースケースを分解し、それぞれの場所で行うべき作業を図 A-1 にまとめる。

図 A-1 システム構成例

このようにまとめると、システムは大きく分けて４つの機能が必要となることがわかる。
１）患者の文書／画像データを登録する機能
２）患者の文書／画像データを参照する機能
３）文書／画像データを保管・管理する機能
４）システムを運用管理する機能
次のステップでは、これらの処理／機能を実現する IHE の業務シナリオ（統合プロファイル）とアクタを見つけ出せばよい。

7

地域医療連携情報システム構築ハンドブック 201１ 附属書

A.3 システムと利用する統合プロファイル／アクタ
１）患者の文書／画像データを登録する機能① XDS の Document Source② XDS-I の Document Image Source③ PIX の Patient Identity Source④ PIX の Patient Identifier Cross-reference Consumer⑤ ATNA の Secure Node
⑥ CT の Time Client２）患者の文書／画像データを参照する機能① XDS の Document Consumer② XDS-I の Document Image Consumer③ PIX の Patient Identifier Cross-reference Consumer④ ATNA の Secure Node
⑤ CT の Time Client３）文書／画像データを保管・管理する機能① XDS の Document Repository② XDS の Document Registry４）システムを運用管理する機能① ATNA の Audit Record Repository② CT の Time Server③ PIX の Patient Identifier Cross-reference Manager④ PDQ の Patient Demographic Supplier
A.4 仕様書記載ポイント（例）
画像データの交換の場合、画像データの本体をどこに格納・保存するかによりシステム
構成が大きく異なる。その構成により仕様書の記載も異なる。ここでは、次のようなシステムを構築するための仕様書例を紹介したい。
＜システム案＞
データ登録：各医療機関
データ参照：各医療機関
文書データ格納：地域連携システムサーバ
画像データ格納：各医療機関の画像サーバ＜システム・運用例＞
ユースケース概要をもう尐しブレイクダウンし、本システムを利用する場面ごとに必要な

8

地域医療連携情報システム構築ハンドブック 201１ 附属書機能を整理する。

4.1 ユーザ登録＜操作者：紹介元の医師・担当者＞
・ コンサルテーションを希望する医療機関の医師は事前に、本コンサルテーショ
ンシステムにユーザ登録をする。
・ コンサル希望医師は、重粒子医科学センター病院ホームページに掲載する本システムの URL にアクセスし、ユーザ登録申請をする。申請時の入力項目は、
医療機関名、所在、電話番号、FAX 番号、医師の所属診療科、医師名（漢字、カナ、ローマ字）等
4.2 ユーザ登録受付＜操作者：コンサルシステム運用管理者＞
・ 放医研のコンサルシステム運用管理者は、ユーザ登録申請を受領し、申請内
容が正しいことを物理的な手段（電話、郵便、FAX 等）で確認する。
・ ユーザ登録申請の許可ができた場合は、本登録の手続きを行う。
4.3 コンサルテーション依頼＜操作者：紹介元の医師・担当者＞
・ コンサルしたい患者の情報を登録する。登録する情報は、患者基本情報、疾患情報（部位、組織型、TNM、stage）、前治療、現病歴、重複癌有無、依頼内
容、画像（直接登録、別途 CD 送付）など。
・ システムから、コンサル番号（以降のキー情報）が発行される。画像を媒体で送付する場合はコンサル内容が印刷できる。
4.4 コンサルテーション振分け＜操作者：放医研の相談窓口担当者＞
・ コンサル状況一覧が表示される。一覧は、依頼日、依頼元、状況（未処理／
回答待ち／回答済／医師処理中／医師回答遅延）、疾患情報、回答担当
医、画像到着状況などが表示される。
・ “未処理”（＝新規依頼）について、コンサル内容をみて、適切な疾患グループの担当医にコンサル依頼。
・ コンサル内容から以前にも紹介があった患者の場合は、過去情報を検索し過去コンサル歴と関連付けを行い、放医研担当医が容易に両方の情報を参照
できるよう設定を行う。
・ “回答遅延”のものは、回答担当医に再度要求する。
・ “回答待ち“のものは、依頼元へ回答担当医の回答と、受診時の必要事項をまとめて送付する。依頼元へは自動的にコンサル番号を基にした回答有等のメールが通知される。
4.5 コンサルテーション依頼内容参照・回答＜操作者：放医研の医師＞
・ コンサル依頼内容をみて、治療適応有無を回答する。
・ 治療適応有（＝放医研で治療可）の場合、治療内容、治療予定、コメント、注意事項等。
・ 治療適応無の場合、理由を回答。
4.6 コンサルテーション回答参照＜操作者：紹介元の医師・担当者＞
・ コンサルテーションシステムにアクセスし回答を参照する。
4.7 受診予約＜操作者：紹介元の医師・担当者＞
・ 患者が希望する場合は、コンサルテーションシステムを利用して初診予約をとる。
4.8 受診＜操作者：放医研の医師＞
・ コンサル番号から、当該患者の病歴情報等を参照する。
4.9 治療 ・・・ 院内電子カルテへの取り込みは次期システムで検討

9

地域医療連携情報システム構築ハンドブック 201１ 附属書

4.10 フォローアップ依頼＜操作者：放医研の医師＞
・ コンサル番号を元に、治療サマリを記載し、フォローアップを依頼する。
・・・院内電子カルテ／DB システムから、治療サマリ情報の取得は次期システムで検討。
4.11 フォローアップ登録＜操作者：フォローアップ担当医＞
・ フォローアップ依頼を受けた医療機関は、定期的な患者の受診を契機に、治療のフォローを行う。
・ 治療フォロー時には、医療機関 ID などを元に患者検索を行い、コンサルテー
ション番号に対してフォローアップ情報の登録や連絡事項などを記載する。
・ フォローアップ情報として登録する項目は、フォローアップ実施日、転帰、副作用（部位ごと）、腫瘍サイズ、再発・再燃有無、画像情報等である。
4.12 再治療依頼＜操作者：フォローアップ担当医＞
・ 定期的なフォローアップ時に、腫瘍の再発/転移が認められた場合は、再度コンサルテーションを開始する。このとき、新たにコンサル番号を取得する。

＜システム・仕様書例・抜粋＞
ブレイクダウンしたシナリオを元に、本システムの各機能を設置する場所ごとに必要な要件と機能をまとめる。この時、各システムで実現する IHE の統合プロファイルとアクタを明記することで整理する。ここでは患者の文書／画像データ登録機能について記載する。

1)

患者の文書／画像データを登録する機能a)
コンサルしたい患者の情報を登録する機能を有すること。登録する情報
は、患者基本情報、疾患情報（部位、組織型、TNM、stage）、前治療、現病歴、重複癌有無、依頼内容、画像（直接登録、別途 CD 送付）などである。
b)
文書情報の登録は、IHE-IT インフラストラクチャ・XDS 統合プロファルのDocument Source アクタを利用して実現すること。
c)
画像情報の登録は、IHE-IT インフラストラクチャ・XDS-I の Document
Image Source アクタを利用して実現すること。
d)
患者情報の登録前に地域連携システム上の患者 ID との整合をとる必要がある。本システムでは地域連携サーバ室に患者情報管理機能が設置されているので、必要な情報を検索し患者が地域連携システムで一意に決まる ID を取得する。地域連携サーバ室にある患者情報管理機能はPIX 統合プロファイルの Patient Identifier Cross-reference Manager アクタ、および PDQ 統合プロファイルの Patient Demographic Supplier アクタを実現する。文書情報登録機能は、PIX の Patient Identity Source アクタおよび Patient Demographic Consumer アクタを実現し、ITI テクニカル
フレームワークで指定した通信手順（トランザクション）によって患者情報を取得することとする。
e)
地域連携サーバに登録時には登録した旨を示す監査証跡ログを出力すること。監査証跡ログの出力は、IHE-IT インフラストラクチャ領域のATNA(Audit Trail and Node Authentication)統合プロファイルの Audit10地域医療連携情報システム構築ハンドブック 201１ 附属書

f)Trail-Secure Node アクタを利用すること。監査証跡ログのイベント ID 等
ログ内容の詳細は別途指定したとおりとすること。
正確な情報収集のために、時刻サーバを導入する予定である。文書登録機能は、指定した時刻サーバと時刻同期を行うこと。時刻同期には、
ITI-IT インフラストラクチャの CT(Consistent Time)統合プロファイルのTime Client アクタを利用すること。時刻同期は１回／日で実施することとする。実施時間は別途調整する。

11

地域医療連携情報システム構築ハンドブック 201１ 附属書

附属書 B.

XDS 概説

本附属書では、IHE テクニカルフレームワーク（IHE-ITI-TF-1、2、3 Rev.8）に沿って
XDS の技術的な概要を説明する。
IHE-ITI-TF の Rev.6 まで、XDS は「XDS.a」と「XDS.b」の 2 種類の仕様が存在していた。
両者の違いは、XDS のベースとなっている ebXML のバージョン、トランザクションの通信方式、メタデータの属性が一部異なる点などがある。しかし IHE-ITI-TF の Rev.7 に
おいて XDS.a は廃止となり、現時点では XDS.b のみとなっている。従って、本書では「XDS.b」の技術的な概要を説明する。以下、「XDS」は「XDS.b」を指すものとする。
なお附属書 J では、XDS.b を実装したオープンソース及びその利用方法を紹介する。
B.1 XDS のアクタとトランザクション
XDS は表 B-１に示す５つのアクタ、及び表 B-2 に示す６つのトランザクションから構成される。
表 B-1 XDS を構成するアクタ
アクタ
ドキュメントソース（DocumentSource：文書供給源）

概要
文書（ファイル）および文書のインデックス情報（メタデータ）を提供する。

ドキュメントリポジトリ
文書そのものを保管する（DocumentRepository：文書保管庫）
ドキュメントレジストリ（DocumentRegistry：文書登録簿）

文書のメタデータを保管する

ドキュメントコンシューマ
文書の検索・参照を行う（DocumentConsumer：文書利用者）
患者IDソース（Patient Identity Feed）

患者IDを提供する

12

地域医療連携情報システム構築ハンドブック 201１ 附属書

表 B-2 XDS で取り扱うトランザクション
トランザクション

概要

Provide and Register Document
Set-b [ITI-41]

ドキュメントソースからドキュメントリポジトリへ文書と、そのインデックス情報（メタデータ）を送る。

Register Document Set-b[ITI-42]

ドキュメントリポジトリからドキュメントレジストリへメ
タデータを登録する。

Registry Stored Query [ITI-18]

検索処理により、ドキュメントコンシューマが、ドキュ
メントレジストリからメタデータを取り出す。

Retrieve Document Set [ITI-43]

ドキュメントコンシューマが、ドキュメントレジストリ
から文書を取り出す。

Patient Identity Feed [ITI-8]

ドキュメントレジストリへドメイン内の患者IDの提供を行う（HL7v2形式に基づく）

Patient Identity Feed HL7v3[ITI-44]

ドキュメントレジストリへドメイン内の患者IDの提供を行う（HL7v3形式に基づく）

XDS におけるアクタとトランザクションの関係は図 B-1 のとおりである。

患者IDソース
Patient Identity
Feed [ITI-8]

Patient Identity
Feed HL7v3 [ITI-44]

ドキュメント
レジストリ
RegisterDocument
Set-b [ITI-42]

ドキュメントソース

Provide&Register
Document
Set-b [ITI-41]

ドキュメント
リポジトリ

RegistryStored Query[ITI-18]

ドキュメントコンシューマRetrieve Document Set [ITI-43]

図 B-1 XDS のアクタとトランザクション

なお XDS では、トランザクション、メタデータのスタイルなどで既存の仕様を参照している。XDS に取り入れている既存の仕様を表 B-3 に示す。

13

地域医療連携情報システム構築ハンドブック 201１ 附属書

表 B-3 XDS の参照仕様1
参照技術

使用場面

ebXML ver.3.0

メタデータの記述形式

SOAP1.2

トランザクション間の通信（患者IDソースに関するトランザクションを除く）

MTOM/XOP

トランザクション[ITI-41]、[ITI-43]で文書とメタデータの送信に使用

HL7

患者IDソースから患者IDを供給する、および患者の個人情報をメタデータに記述するときに使用

以後は、ドキュメントソース、ドキュメントリポジトリ、ドキュメントレジストリおよびドキュメン
トコンシューマは便宜上ソース、リポジトリ、レジストリおよびコンシューマと略する。
この中で患者 ID ソースについては PIX 統合プロファイルで定義されるため、ここではXDS 固有であり、かつ基本的なアクタであるソース、リポジトリ、レジストリ、コンシューマ
を主に説明する。
B.2 XDS における処理の流れ
XDS では主要な処理として「文書2・メタデータ登録」「メタデータ検索」「文書の取得」の三つがある。本節では各処理について説明する。
（ア）文書・メタデータ登録
ドキュメントソースからドキュメントリポジトリおよびドキュメントレジストリに対して文書およ
びそのメタデータの登録を実行する。具体的には以下の（イ）（ロ）を順に実行する。
（イ）ソースからリポジトリへの登録要求（ProvideAndRegisterDocumentSet-b[ITI-41]：図 B-2）
ソースにおいて、リポジトリに登録する文書を１つ以上選定し、文書一つにつき一つのメタデータを作成する。このメタデータは文書に対するインデックス情報となる。文書とそれに対応するメタデータはリポジトリへ送られる。
リポジトリでは、ソースから受け取った文書とメタデータから文書を取り出して保存する。

表中に挙げた参照技術の正式名称と参照先は以下の通り。

1

ebXML：Electronic Business using eXtensible Markup Language、
ebXML レジストリについて http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep
を参照
SOAP：Simple Object Access Protocol、（SOAP1.2）http://www.w3.org/TR/soap12-part0/
MTOM：Message Transmission Optimization Mechanism、http://www.w3.org/TR/soap12-mtom/
XOP：XML-binary Optimized Packaging、http://www.w3.org/TR/xop10/
HL7：Health Level Seven、http;//www.hl7.org/、http://www.hl7.jp
2
本章における「文書」とは、単なるテキストファイルだけでなく、CDA などの XML 文書、DICOM などの画像なども含めた、コンピュータにおいて一般的に「ファイル」と呼ばれるものすべてを指すものとする。

14

地域医療連携情報システム構築ハンドブック 201１ 附属書

患者IDソース

文書ファイルの保存・登録文書選定
・文書のメタデー
タ作成
ドキュメントレジストリ

ドキュメントソース

ドキュメントコンシューマドキュメント
リポジトリ

文書ファイル＋メタデータ

図 B-2 ソースからリポジトリへの登録要求（ロ）リポジトリからレジストリへの登録要求（RegisterDocumentSet-b[ITI-42]：図 B-3）
ソースからの登録要求メッセージから文書を取り出し保存した後、リポジトリはその文書の情報（ハッシュ値、サイズ）、及びリポジトリに対して付与されている ID 値（リポジトリ ID）
を文書に対応するメタデータに埋め込む。その上でメタデータをレジストリへ送付する。
レジストリでは、リポジトリから受け取ったメタデータを保存する。なお、レジストリにてエラーが発生した場合はその内容をリポジトリ経由でソースへ送る。

患者IDの供給
メタデータのチェック
メタデータの登録

患者IDソース

ドキュメント
レジストリ

文書ファイルの保存

ドキュメントコンシューマ文書メタデータ

ドキュメントソース

ドキュメント
リポジトリ
文書ファイルの情報（リポジト
リのID、ハッシュ値、サイズ）をメタデータに付与

図 B-3 リポジトリからレジストリへの登録要求（１）メタデータ検索（RegistryStoredQuery[ITI-18]：図 B-4）

15

地域医療連携情報システム構築ハンドブック 201１ 附属書コンシューマは、レジストリからメタデータを取得するために、検索条件を含めた検索要
求メッセージをレジストリへ送る。
レジストリは検索要求メッセージを受け取ると、検索条件に応じたメタデータを検索結果としてコンシューマへ送る。
コンシューマは検索結果をレジストリから受け取ると、コンシューマ利用者に検索結果を提示する。
患者IDソース

文書のメタデータ
検索要求

ドキュメントレジストリ

ドキュメントコンシューマ

検索結果
ドキュメントリポジトリ

ドキュメントソース

図 B-4 コンシューマからレジストリへの検索要求

なお、メタデータ検索においてはストアドクエリ(StoredQuery)を利用する。XDS において定義されているストアドクエリの種類を表 B-4 に示す。各クエリの詳細及び定義は
ITI-TF-2a の 3.18.4.1.2.3.7 を参照のこと。

表 B-4 XDS におけるストアドクエリの種類
FindDocuments

GetDocument

GetRelatedDocuments

FindFolders

GetSubmissionSetAndContents

GetFolders

FindSubmissionSets

GetFolderAndContents

GetAssociations

GetAll

GetFoldersForDocument

GetDocumentsAndAssociations

GetSubmissionset（１）文書の取得（RetrieveDocumentSet[ITI-43]：図 B-5）
前述のメタデータ検索の実行で、取得したい文書のメタデータが得られると、その中に文書がどのリポジトリに存在するかを表す情報（文書所在情報）が含まれている。その情報をもとに、該当のリポジトリに対して文書取得要求メッセージを送る。
リポジトリは文書取得要求メッセージを受け取ると、要求された文書をコンシューマに送る。コンシューマはリポジトリからの文書を受け取ると、文書の表示などを実行してコン
シューマ利用者に提示する。

16

地域医療連携情報システム構築ハンドブック 201１ 附属書

患者IDソース

ドキュメントレジストリ

ドキュメントソース

文書所在情報ドキュメントコンシューマドキュメント
リポジトリ
文書取得要求図 B-5 文書の取得要求

B.3 メタデータの種類
XDS で取り扱うメタデータは、・ドキュメントエントリ（DocumentEntry）
・フォルダ（Folder）
・サブミッションセット（SubmissionSet）
・アソシエーション（Association）の４種類がある。これらはすべてレジストリで管理される。
B.1 節で触れたように、XDS は ebXML の技術をベースにしているため、XDS で取り扱う
メタデータを記述するとき、ebXML レジストリ情報モデル(ebXML Registry Information
Model: ebXML RIM)ver3.0 の流儀に沿って書く必要がある。ドキュメントエントリは
ebXML RIM ver3.0 で定義されている「ExtrinsicObject」として、フォルダ及びサブミッションセットは ebXML RIM ver3.0 での「RegistryPackage」としてそれぞれ記述する。
こ れ ら の 関 係 を 図 B-6 に 示 す 。 フ ォ ル ダ と サ ブ ミ ッ シ ョ ン セ ッ ト は ど ち ら もRegistryPackage を用いて記述するが、両者の区別を付けるために ebXML RIM ver3.0
での「Classification」を利用する。
なおアソシエーションについては ebXML RIM ver3.0 で定義されている「Association」をそのまま取り入れている。

17

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 B-6 メタデータにおける XDS と ebXML の対応

以下に XDS で取り扱うメタデータが持つ属性の種類を取り上げる。
（１） ドキュメントエントリ（DocumentEntry）
ドキュメントエントリには、リポジトリへ登録する文書のインデックス情報を記述する。
表 B-5 にドキュメントエントリが持つ属性の項目を挙げる。各項目の詳細及び設定方法
は ITI-TF-3 の４．１．７を参照のこと。各項目は ebXML RIM ver3.0 で定義されている
Slot、Classification、ExternalIdentifier、Name、Description を利用して設定される。
表 B-5 ドキュメントエントリの属性一覧
項目

必要性

項目

必要性

authorR2

homeCommunityId

Cx

authorInstitution

R2

languageCodeR

authorPerson

R2

legalAuthenticatorO

authorRole

R2

mimeTypeRauthorSpecialty

R2patientId

R

availabilityStatus

Cg

practiceSettingCode

R

classCodeR

practiceSettingCodeDisplayName

R

classCodeDisplayName

R

repositoryUniqueId

Cp

comments

O

serviceStartTime

R2

confidentialityCode

R

serviceStopTime

R2

creationTime

R

size

Cp

entryUUID

Cg

sourcePatientId

R

eventCodeList

OsourcePatientInfo

O

eventCodeDisplayName

O

title

O

formatCode

R

typeCode

R

hash

Cp

typeCodeDisplayName

R

healthcareFacilityCode

R

uniqueIdR

healthcareFacilityCodeDisplayName

R

URI

Cy

凡例 R：必須 R2：明らかであればできるだけ記入する O：任意 Cg：レジストリにて設定（必須）Cx：レジストリにて設定（必須） Cp：リポジトリにて設定（必須） Cy：リポジトリにて設定（任意）前述の通り、ドキュメントエントリは ebXML RIM ver.3.0 で定義される ExtrinsicObject を利用して記述する。以下、図 B-7 にソース側が作成したドキュメントエントリの xml 形式

18

地域医療連携情報システム構築ハンドブック 201１ 附属書による記述例を示す。
<rim:ExtrinsicObject xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
id="urn:uuid:ee2ed13d-fee6-4239-affa-984c07171ee3"
mimeType="text/plain" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"><!-- Slotを使って定義するメタデータ -- ><rim:Slot name="creationTime"><rim:ValueList><rim:Value>20051224</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="languageCode"><rim:ValueList><rim:Value>en-us</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="sourcePatientId"><rim:ValueList><rim:Value>89765a87b^^^&amp;3.4.5&amp;ISO</rim:Value></rim:ValueList></rim:Slot><!– title, comment -- ><rim:Name><rim:LocalizedString value="Physical"/></rim:Name><rim:Description/><!-- Classificationを利用して定義するメタデータ -- ><rim:Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"classifiedObject="urn:uuid:ee2ed13d-fee6-4239-affa-984c07171ee3"
nodeRepresentation="History and Physical“ id="id_3"><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Connect-a-thon classCodes</rim:Value></rim:ValueList></rim:Slot><rim:Name><rim:LocalizedString value="History and Physical“ /></rim:Name></rim:Classification><!-- 他、confidentialityCode, formatCode, healthcareFacilityTypeCode, practiceSettingCodeが必須だが、スペースの関係で省略 -- ><!-- ExternalIdentifierを利用して定義するメタデータ -- ><rim:ExternalIdentifier identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
value="39a444b558a344c^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"
id="id_9"
registryObject="urn:uuid:ee2ed13d-fee6-4239-affa-984c07171ee3"><rim:Name><rim:LocalizedString value="XDSDocumentEntry.patientId" /></rim:Name></rim:ExternalIdentifier><rim:ExternalIdentifier identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
value="160.27.80.47.1.40" id="id_10"
registryObject="urn:uuid:ee2ed13d-fee6-4239-affa-984c07171ee3"><rim:Name><rim:LocalizedString value="XDSDocumentEntry.uniqueId" /></rim:Name></rim:ExternalIdentifier></rim:ExtrinsicObject>

注： 必要性がR2、Oである属性の内、省略しているものがある。

図 B-7 ドキュメントソース側で作成したドキュメントエントリの例

19地域医療連携情報システム構築ハンドブック 201１ 附属書（２）フォルダ（Folder）
フォルダは目的に応じて複数のドキュメントエントリを束ねるのに用いる。属性の項目
一覧を表 B-6 に示す。各属性の詳細は ITI-TF-3 の 4.1.9 を参照のこと。
表 B-6 フォルダの属性一覧
項目

必要性

項目

必要性

availabilityStatus

Cg

homeCommunityId

Cx

codeList

R

lastUpdateTime

Cg

codeListDisplayName

R

patientId

R

comments

O

title

O

entryUUID

Cg

uniqueIdR

凡例 R：必須 R2：明らかであればできるだけ記入する O：任意 Cg：レジストリにて設定（必須）Cx：レジストリにて設定（任意）ドキュメントフォルダは、図 B-6 に示すように、ebXML RIM で定義されている
RegistryPackage を利用する。またこの RegistryPackage が「フォルダ」であることを示すために、同じ ebXML RIM で定義されている Classification を用いる。図 B-8 にドキュメ
ントフォルダの xml 形式による記述例を示す。

20

地域医療連携情報システム構築ハンドブック 201１ 附属書<rim:RegistryPackage id="urn:uuid:aae617af-af0f-4a29-979d-8683a8511ba7“
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"><!-- title, comment -- ><rim:Name><rim:LocalizedString value="FOLDER" /></rim:Name><rim:Description><rim:LocalizedString value="comments go here" /></rim:Description><!-- Classificationを使って定義するメタデータ： codeList -- ><rim:Classification classificationScheme="urn:uuid:1ba97051-7806-41a8-a48b-8fce7af683c5"
classifiedObject="urn:uuid:aae617af-af0f-4a29-979d-8683a8511ba7"
nodeRepresentation="Referrals“ id="id_12"><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Connect-a-thon folderCodeList</rim:Value></rim:ValueList></rim:Slot><rim:Name><rim:LocalizedString value="Referrals" /></rim:Name></rim:Classification><!-- ExternalIdentifierを利用して定義するメタデータ -- ><rim:ExternalIdentifier identificationScheme="urn:uuid:75df8f67-9973-4fbe-a900-df66cefecc5a"
value="160.27.80.47.1.53"
id="id_13" registryObject="urn:uuid:aae617af-af0f-4a29-979d-8683a8511ba7"><rim:Name><rim:LocalizedString value="XDSFolder.uniqueId" /></rim:Name></rim:ExternalIdentifier><rim:ExternalIdentifier identificationScheme="urn:uuid:f64ffdf0-4b97-4e06-b79f-a52b38ec2f8a"
value="39a444b558a344c^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"
id="id_14" registryObject="urn:uuid:aae617af-af0f-4a29-979d-8683a8511ba7"><rim:Name><rim:LocalizedString value="XDSFolder.patientId" /></rim:Name></rim:ExternalIdentifier></rim:RegistryPackage><!-- 上記RegistryPackageが「フォルダ」であることを定義するClassification。RegistryPackage内に入れてもよい -- ><rim:Classification xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
classifiedObject="urn:uuid:aae617af-af0f-4a29-979d-8683a8511ba7"
classificationNode="urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2"
id="urn:uuid:307875ac-c587-490f-af9e-ba0a46769b62" ></rim:Classification>

図 B-8 ドキュメントソース側で作成するドキュメントフォルダの例（３）サブミッションセット（SubmissionSet）
サブミッションセットは、ドキュメントをレジストリに登録（提供）する際のドキュメントエント
リおよびフォルダに関する情報を含むメタデータの集合を表す。サブミッションセットは一回の登録につき、必ず一つ必要となる。
表 B-7 にサブミッションセットの属性項目一覧を示す。また各属性の詳細は ITI-TF-3の 4.1.8 を参照のこと。

21

地域医療連携情報システム構築ハンドブック 201１ 附属書

表 B-7 サブミッションセットの属性一覧
項目

必要性

項目

必要性

authorR2

entryUUID

Cg

authorInstitution

R2

homeCommunityId

Cx

authorPerson

OintendedRecipientO

authorRole

R2

patientId

R

authorSpecialty

R2sourceId

R

availabilityStatus

Cg

submissionTime

R

comments

O

title

O

contentTypeCodeR

uniqueId

R

contentTypeCodeDisplayNameR

凡例 R：必須 R2：明らかであればできるだけ記入する O：任意 Cg：レジストリにて設定（必須）Cx：レジストリにて設定（任意）サブミッションセットは、図 B-6 に示すように、ebXML RIM で定義されている
RegistryPackage を利用する。またこの RegistryPackage が「サブミッションセット」であることを示すために、同じ ebXML RIM で定義されている Classification を用いる。図 B-9にサブミッションセットの xml 形式による記述例を示す。

22

地域医療連携情報システム構築ハンドブック 201１ 附属書<rim:RegistryPackage id="urn:uuid:a83d67b2-210b-41ac-80e4-9c81c6b16d26"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"><!-- Slotを利用して定義するメタデータ-- ><rim:Slot name="submissionTime"><rim:ValueList><rim:Value>20041225235050</rim:Value></rim:ValueList></rim:Slot><!-- title,comment -- ><rim:Name><rim:LocalizedString value="Physical" /></rim:Name><rim:Description><rim:LocalizedString value="Annual physical" /></rim:Description><!-- Classificationを利用して定義するメタデータ -- ><rim:Classification classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
classifiedObject="urn:uuid:a83d67b2-210b-41ac-80e4-9c81c6b16d26"
nodeRepresentation="History and Physical" id="id_16"><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Connect-a-thon contentTypeCodes</rim:Value></rim:ValueList></rim:Slot><rim:Name><rim:LocalizedString value="History and Physical"/></rim:Name></rim:Classification><!-- ExternalIdetifierを利用して定義するメタデータ -- ><rim:ExternalIdentifier identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8"
value="160.27.80.47.1.52"
id="id_17" registryObject="urn:uuid:a83d67b2-210b-41ac-80e4-9c81c6b16d26"><rim:Name><rim:LocalizedString value="XDSSubmissionSet.uniqueId"/></rim:Name></rim:ExternalIdentifier><rim:ExternalIdentifier identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832"
value="1.3.6.1.4.1.21367.2009.1.&#xD;&#xA;d02&#xD;&#xA;2.1"
id="id_18" registryObject="urn:uuid:a83d67b2-210b-41ac-80e4-9c81c6b16d26"><rim:Name><rim:LocalizedString value="XDSSubmissionSet.sourceId"/></rim:Name></rim:ExternalIdentifier><rim:ExternalIdentifier identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446"
value="39a444b558a344c^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"
id="id_19" registryObject="urn:uuid:a83d67b2-210b-41ac-80e4-9c81c6b16d26"><rim:Name><rim:LocalizedString value="XDSSubmissionSet.patientId"/></rim:Name></rim:ExternalIdentifier></rim:RegistryPackage><!-- 上記RegistryPackageが「サブミッションセット」であることを定義するClassification。RegistryPackage内で入れてもよい -- ><rim:Classification xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
classifiedObject="urn:uuid:a83d67b2-210b-41ac-80e4-9c81c6b16d26"
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"
id="urn:uuid:895fbb6f-dc68-46a6-81c2-b340a1b53e77" ></rim:Classification>
注： 必要性がR2、Oである属性の内、省略しているものがある。

図 B-9 ドキュメントソース側で作成するサブミッションセットの例

23地域医療連携情報システム構築ハンドブック 201１ 附属書（４）コードの定義
上記（１）～（３）で説明したメタデータの属性の中には、あらかじめ定義されたコードの中から選択して決めるものがある。ドキュメントエントリの classCode、フォルダのcodeList、サブミッションセットの contentTypeCode など、属性名に「Code」を含み、ebXMLRIM の Classification を利用して設定される属性がこれに当たる。コードの定義
は XDS アフィニティドメインの一部として定義される。一例として、図 B-10 にドキュメン
トエントリで設定される confidentialityCode の定義例を示す。また、IHE のサイト3及び
JAHIS の技術文書4からもコードの定義を参照することができる。
<CodeType name="confidentialityCode" classScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"><Code code="N" display="Normal" codingScheme="2.16.840.1.113883.5.25"/><Code code="R" display="Restricted" codingScheme="2.16.840.1.113883.5.25"/><Code code="V" display="very restricted" codingScheme="2.16.840.1.113883.5.25"/><Code code="C" display="Celebrity" codingScheme="Connect-a-thon confidentialityCodes"/><Code code="D" display="Clinician" codingScheme="Connect-a-thon confidentialityCodes"/><Code code="I" display="Individual" codingScheme="Connect-a-thon confidentialityCodes"/><Code code="N" display="Normal" codingScheme="Connect-a-thon confidentialityCodes"/><Code code="R" display="Restricted" codingScheme="Connect-a-thon confidentialityCodes"/><Code code="S" display="Sensitive" codingScheme="Connect-a-thon confidentialityCodes"/><Code code="T" display="Taboo" codingScheme="Connect-a-thon confidentialityCodes"/></CodeType>

図 B-10 confidentialityCode の定義例

（１）アソシエーション（Association）
アソシエーションはメタデータ間の関連を表す。これは ebXML RIM で定義された「Association」をそのまま利用する。
表 B-8 アソシエーションの属性一覧
項目

必要性

id

Cg

sourceObject

RtargetObject

RassociationTypeR

凡例 R：必須
Cg：レジストリにて設定

アソシエーションは以下の場面で使用する。
・フォルダによるドキュメントエントリ集合構築
・サブミッションセットを用いた登録単位の作成
・ドキュメント間の関連
3 http://ihexds.nist.gov/xdsref/codes/codes.xml
4「地域医療連携システム 診察情報共有化のための IHE XDS 適用ガイド」（JAHIS 技術文書 09-101）の 7.章参照 http://www.jahis.jp/standard/seitei/st09-101v1.0a/st09-101v1.0a.pdf

24地域医療連携情報システム構築ハンドブック 201１ 附属書

以下、これらを順に説明する。
・フォルダによるドキュメントエントリ集合構築
上述（２）で述べたとおり、フォルダは複数のドキュメントエントリを束ねるのに利用されるが、その際にアソシエーションを利用する。図 B-11 はその一例である。

DocumentEntry1
Association1
Folder

Association2

DocumentEntry2

Association3
DocumentEntry3

図 B-11 フォルダによるドキュメントエントリ集合の例

この場合、各アソシエーションの属性値はそれぞれ以下のように設定する（表 B-9、図B-12）。
表 B-9 属性値の設定
項目値

sourceObject

FolderのentryUUID

targetObject（Association1の場合）DocumentEntry1のentryUUID（Association2の場合）DocumentEntry2のentryUUID（Association3の場合）DocumentEntry3のentryUUID

associationType urn:oasis:names:tc:ebxml-regrep:AssocaitionType:HasMember25

地域医療連携情報システム構築ハンドブック 201１ 附属書<rim:Association id=“Association1のid"
associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember“
sourceObject="FolderのentryUUID"
targetObject="DocumentEntry1のentryUUID" ></rim:Association><rim:Association id="Association2のid"
associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember“
sourceObject="FolderのentryUUID"
targetObject="DocumentEntry2のentryUUID" ></rim:Association><rim:Association id="Association3のid"
associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember“
sourceObject="FolderのentryUUID"
targetObject="DocumentEntry3のentryUUID" ></rim:Association>

図 B-12 アソシエーション設定例

・サブミッションセットを用いた登録単位の作成
上述（３）で述べたように、サブミッションセットは、ドキュメントをレジストリに登録（提供）する際のドキュメントエントリおよびフォルダに関する情報を含むメタデータの集合を表す。この集合を構成するのにアソシエーションを利用する。この場合、サブミッションセ
ットと他のメタデータとのアソシエーションが持つ属性値は次のようになる（表 B-10）。
表 B-10 属性値の設定
項目値

sourceObject

サブミッションセットのentryUUID

targetObject

ドキュメントエントリ、フォルダのentryUUID、あるいはフォルダ、ドキュメントエントリ間サブミッションセットのid

associationTypeurn:oasis:names:tc:ebxml-regrep:AssocaitionType:HasMember

図 B-13 に例を示す。

SubmissionSet
Association 3
DocumentEntry
Association 2
Association 1

Association X

Folder26

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 B-13 サブミッションセットを利用した登録単位の例

本例において、Association1 から Association3 の属性値はそれぞれ以下の値をとる。
表 B-11 属性値の設定
項目値

sourceObject

SubmissionSetのentryUUID

targetObject(Assoxiation1の場合)FolderのentryUUID(Assocaition2の場合)AssociationXのid(Association3の場合)DocumentEntryのentryUUID

associationTypeurn:oasis:names:tc:ebxml-regrep:AssocaitionType:HasMember

・ドキュメント間の関連
XDS では２つの文書の関係を定義できる。具体的には文書に対するドキュメントエント
リとの間の関係を、アソシエーションを利用して定義するもので、定義可能な関係は以下のとおり。
表 B-12 文書間関係
文書間関係

説明

差し替え
（Replacement：RPLC）

targetObjectで指定した文書を、sourceObjectで指定した文書に差し替える

添付（Addendum：APND）

targetObjectで指定した文書に、sourceObjectで指定した文書
を追加する

変換
（Transformation：XFRM）

sourceObjectで指定した文書はtargetObjectで指定した文書を（翻訳などを行って）変換したものを表す。

変換・差し替えsourceObjectで指定した文書はtargetObjectで指定した文書を（Transformation-Replacement： （翻訳などを行って）変換したものであり、かつtargetObjectで指定した文書を、sourceObjectで指定した文書に差し替える。
XFRM_RPLC）
署名（ｓigns）

sourceObjectで指定した文書はtargetObjectで指定した文書の電子署名であることを表す。

表 B-13 文書間関係と associationType での設定値
文書間関係

associationTypeでの設定値

差し替え（RPLC）

urn:ihe:iti:2007:AssociationType:RPLC

添付（APND）

urn:ihe:iti:2007:AssociationType:APND

変換（XFRM）

urn:ihe:iti:2007:AssociationType:XFRM

変換・差し替え（XFRM_RPLC）

urn:ihe:iti:2007:AssociationType:XFRM_RPLC

署名（ｓigns）

urn:ihe:iti:2007:AssociationType:signs

図 B-14 に例を示す。本例では２つのドキュメントエントリ DocumentEntry1 とDocumentEntry2 があり、DocumentEntry1 は既にレジストリへ登録されていて、これを27

地域医療連携情報システム構築ハンドブック 201１ 附属書「差し替える」ために DocumentEntry2 を登録する。

DocumentEntry2（差し替え文書）

DocumentEntry1（レジストリ登録済）

Association

図 B-14 ２つの文書の対応関係（差し替え）の例

この場合、アソシエーションの各属性は以下のようになる（表 B-14）。

表 B-14 各属性の設定値
項目値

sourceObject

DocumentEntry2のentryUUID

targetObject

DocumentEntry1のentryUUID

associationTypeurn:ihe:iti:2007:AssociationType:RPLC

なお、文書の差し替えでは、差し替えられた文書（上記の例では DocumentEntry1）の属性 availabilityStatus の値がレジストリ側で変更される。このように文書間関連の設定においては、表 B-12 に定義した関係に応じて追加で行うべき処理が存在する。文書
間関連の詳細については ITI-TF-3 の 4.1.6 項を参照のこと。
B.4 トランザクションの通信方式
XDS を構成するソース、リポジトリ、レジストリ及びコンシューマの各アクタ間のトランザクションでは、通信の方式として SOAP1.2 を採用している。さらに文書本体を取り扱う[ITI-41]と[ITI-43]では、SOAP1.2 に加え MTOM/XOP（MTOM with XOP encoding）
形式を利用することが ITI-TF-2b において規定されている（3.41.5 及び 3.43.5 を参照）。
各トランザクションの通信方式を図示したのが図 B-15 である。

28

地域医療連携情報システム構築ハンドブック 201１ 附属書

患者IDソース[ITI-8][ITI-44]

ドキュメントレジストリ[ITI-18]
SimpleSOAP

ドキュメントコンシューマ[ITI-42]
SimpleSOAP

ドキュメントソース[ITI-41]
MTOM/XOP

ドキュメントリポジトリ[ITI-43]
MTOM/XOP

図 B-15 トランザクションの通信方式

以下、各トランザクションで取り扱われる SOAP メッセージの例を示す。
（１）文書・メタデータ登録[ITI-41]
ソースからリポジトリに対して出される文書登録要求の例を図 B-16 に、その要求例に対する返信メッセージを図 B-17 に示す。文書登録要求だけでなく、要求に対する返信メッセージも MTOM/XOP 形式を利用した SOAP メッセージであることに注意すること。
本例はソースから 1 つの文書を登録する場合の SOAP メッセージを表している。そのためメタデータとして、ドキュメントエントリ、サブミッションセット、アソシエーションが一つずつ SOAP メッセージの Body 部に入っている（ただし、図 B-16 では Slot、Classification、ExternalIdentifier で記述されるメタデータの属性値を省略している）。
また、SOAP メッセージの Body 部の下部に Document タグがあるが、これは文書本体とその文書のドキュメントエントリとの対応を記述する。文書本体は SOAP メッセージの添付データとして取り扱われる。
また、図 B-17 のメッセージは登録が成功した場合の返信メッセージである。これはメッ
セージ中の RegistryResponse タグに含まれる属性値 status が Success であることからわかる（図 B-17 の赤字部分）。もし、エラーが発生して登録が失敗した場合は、この属性値が Failure となり、SOAP の Body 部にエラーの内容が記載されている。

29

地域医療連携情報システム構築ハンドブック 201１ 附属書

POST /tf6/services/xdsrepositoryb HTTP/1.1
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_82378215884CFDAF4E1268820255283;
type="application/xop+xml"; start="<0.urn:uuid:82378215884CFDAF4E1268820255284@apache.org>";
start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"
User-Agent: Axis2
Host: jiji:9080
Transfer-Encoding: chunked--MIMEBoundaryurn_uuid_82378215884CFDAF4E1268820255283
Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:82378215884CFDAF4E1268820255284@apache.org><?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:To>http://elektra:9080/tf6/services/xdsrepositoryb</wsa:To><wsa:MessageID>urn:uuid:82378215884CFDAF4E1268820254957</wsa:MessageID><wsa:Action>urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b</wsa:Action></soapenv:Header><soapenv:Body><xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-b:2007"><lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"><rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"><rim:ExtrinsicObject id="urn:uuid:7a4fc48b-8d20-462a-a8a7-8b94076780eb"
mimeType="text/plain"objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"><!-- 省略-- ></rim:ExtrinsicObject><rim:RegistryPackage id="urn:uuid:a83d67b2-210b-41ac-80e4-9c81c6b16d26"><!-- 省略-- ></rim:RegistryPackage><rim:Classification classifiedObject="urn:uuid:a83d67b2-210b-41ac-80e4-9c81c6b16d26"
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"
id="urn:uuid:895fbb6f-dc68-46a6-81c2-b340a1b53e77"></rim:Classification><rim:Association associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember"sourceObject="urn:uuid:a83d67b2-210b-41ac-80e4-9c81c6b16d26"
targetObject="urn:uuid:7a4fc48b-8d20-462a-a8a7-8b94076780eb"
id="urn:uuid:edc81ecc-d5e8-4eca-a1b7-d3f4c89e41db"></rim:Association></rim:RegistryObjectList></lcm:SubmitObjectsRequest><xdsb:Document id="urn:uuid:7a4fc48b-8d20-462a-a8a7-8b94076780eb"><xop:Include href="cid:1.urn:uuid:82378215884CFDAF4E1268820255652@apache.org"
xmlns:xop="http://www.w3.org/2004/08/xop/include" /></xdsb:Document></xdsb:ProvideAndRegisterDocumentSetRequest></soapenv:Body></soapenv:Envelope>--MIMEBoundaryurn_uuid_82378215884CFDAF4E1268820255283
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID: <1.urn:uuid:82378215884CFDAF4E1268820255652@apache.org>
This is my document.
It is great!

--MIMEBoundaryurn_uuid_82378215884CFDAF4E1268820255283--

図 B-16 ドキュメントソースからの文書登録要求メッセージ

30

メ
タ
デ
ー
タ

文
書
本
体
へ
の
ポ
イ
ン
タ
文
書
本
体

地域医療連携情報システム構築ハンドブック 201１ 附属書HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_D93C36CAA0149E1BB01268820290558;
type="application/xop+xml"; start="0.urn:uuid:D93C36CAA0149E1BB01268820290559@apache.org";
start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse"
Transfer-Encoding: chunked
Date: Wed, 17 Mar 2010 10:04:50 GMT--MIMEBoundaryurn_uuid_D93C36CAA0149E1BB01268820290558
Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:D93C36CAA0149E1BB01268820290559@apache.org><?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:Action>urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse</wsa:Action><wsa:RelatesTo>urn:uuid:82378215884CFDAF4E1268820254957</wsa:RelatesTo></soapenv:Header><soapenv:Body><rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success" /></soapenv:Body></soapenv:Envelope>--MIMEBoundaryurn_uuid_D93C36CAA0149E1BB01268820290558--

図 B-17 ドキュメントレジストリからの返信メッセージ（２）メタデータの登録 [ITI-42]
リポジトリからレジストリに対して出されるメタデータ登録要求の例を図 B-18 に、その要求例に対する返信メッセージを図 B-19 に示す。メタデータの登録要求及びその返信
メッセージは、MTOM/XOP を用いない通常の SOAP メッセージ（SIMPLE SOAP）を利用する。
本例は、リポジトリがソースからの 1 つの文書を登録する要求を受け取り、その中に含まれるメタデータを取り出して文書に関する追加情報（図 B-18 の中央部参照）を付与
し、レジストリにこれらのメタデータを登録しようというものである。そのため SOAP メッセ
ージの Body 部にドキュメントエントリ、サブミッションセット、アソシエーションが各１つ含まれている（ただし、図 B-18 ではメタデータの属性値を省略している）。
また、図 B-19 のメッセージは登録が成功した場合の返信メッセージである。これはメッ
セージ中の RegistryResponse タグに含まれる属性値 status が Success であることからわかる（図 B-19 の赤字部分）もし、エラーが発生して登録が失敗した場合は、この属性値が Failure となり、SOAP の Body 部にエラーの内容が記載されている。

31

地域医療連携情報システム構築ハンドブック 201１ 附属書

POST /tf6/services/xdsregistryb HTTP/1.1
Content-Type: application/soap+xml; charset=UTF-8; action="urn:ihe:iti:2007:RegisterDocumentSet-b"
User-Agent: Axis2
Host: jiji:9080
Transfer-Encoding: chunked<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:To>http://elektra:9080/tf6/services/xdsregistryb</wsa:To><wsa:MessageID>urn:uuid:48F456C97F7F86E4421268909398104</wsa:MessageID><wsa:Action>urn:ihe:iti:2007:RegisterDocumentSet-b</wsa:Action></soapenv:Header><soapenv:Body><lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"><rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"><rim:ExtrinsicObject id="Document01" mimeType="text/plain"objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"><rim:Slot name="repositoryUniqueId"><rim:ValueList><rim:Value>1.19.6.24.109.42.1</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="size"><rim:ValueList><rim:Value>4</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="hash"><rim:ValueList><rim:Value>e543712c0e10501972de13a5bfcbe826c49feb75</rim:Value></rim:ValueList></rim:Slot><!-- 他の属性は省略 -- ></rim:ExtrinsicObject><rim:RegistryPackage id="SubmissionSet01" ><!-- 省略 -- ></rim:RegistryPackage><rim:Classification classifiedObject="SubmissionSet01"
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"
id="ID_16164678_1"></rim:Classification><rim:Association associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember"sourceObject="SubmissionSet01"
targetObject="Document01"
id="ID_16164678_2" ></rim:Association></rim:RegistryObjectList></lcm:SubmitObjectsRequest></soapenv:Body></soapenv:Envelope>

追リ
加ポ
さジ
れト
たリ
属で
性

図 B-18 ドキュメントリポジトリからのメタデータ登録要求

32

メ
タ
デ
ー
タ

地域医療連携情報システム構築ハンドブック 201１ 附属書HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/soap+xml; action="urn:ihe:iti:2007:RegisterDocumentSet-bResponse";charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 18 Mar 2010 10:49:59 GMT<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:Action>urn:ihe:iti:2007:RegisterDocumentSet-bResponse</wsa:Action><wsa:RelatesTo>urn:uuid:48F456C97F7F86E4421268909398104</wsa:RelatesTo></soapenv:Header><soapenv:Body><rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success" /></soapenv:Body></soapenv:Envelope>

図 B-19 ドキュメントレジストリからの返信メッセージ（３）メタデータ検索要求 [ITI-18]
コンシューマからレジストリに対して出されるメタデータ検索要求メッセージの例を図B-20 に、検索要求の例に対する結果（検索結果）のメッセージを図 B-21 にそれぞれ示す。検索要求及び検索結果は、MTOM/XOP を用いない通常の SOAP メッセージ（SIMPLE SOAP）を利用する。
先に触れたとおり、メタデータ検索要求はストアドクエリを利用する。本例では、ストアド
クエリ「GetDocument」に基づくもので、検索条件は uniqueId が「160.27.80.47.54」ある
いは「160.27.80.47.55」であるドキュメントエントリであることを意味する（図 B-20 中にある name が「$XDSDocumentEntryUniqueId」である Slot オブジェクトが検索条件を表す）。
図 B-21 に示す検索結果には、検索により見つかった、uniqueId が「160.27.80.47.54」
であるドキュメントエントリと uniqueId が「160.27.80.47.55」であるドキュメントエントリの 2つが含まれている（ただし、図 B-21 では uniqueId 以外のドキュメントエントリの属性値を省略している）。

33

地域医療連携情報システム構築ハンドブック 201１ 附属書

POST /tf6/services/xdsregistryb HTTP/1.1
Content-Type: application/soap+xml; charset=UTF-8; action="urn:ihe:iti:2007:RegistryStoredQuery"
User-Agent: Axis2
Host: jiji:9080
Transfer-Encoding: chunked<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:To>http://elektra:9080/tf6/services/xdsregistryb</wsa:To><wsa:MessageID>urn:uuid:6C0A7AC4D92351F45B1268908706961</wsa:MessageID><wsa:Action>urn:ihe:iti:2007:RegistryStoredQuery</wsa:Action></soapenv:Header><soapenv:Body><query:AdhocQueryRequest xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"><query:ResponseOption returnComposedObjects="true" returnType="LeafClass" /><AdhocQuery id="urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4"><Slot name="$XDSDocumentEntryUniqueId"><ValueList><Value>('160.27.80.47.1.54', '160.27.80.47.1.55')</Value></ValueList></Slot></AdhocQuery></query:AdhocQueryRequest></soapenv:Body></soapenv:Envelope>

図 B-20 ドキュメントレジストリへの検索要求

34

地域医療連携情報システム構築ハンドブック 201１ 附属書HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/soap+xml; action="urn:ihe:iti:2007:RegistryStoredQueryResponse";charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 18 Mar 2010 10:38:28 GMT<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:Action>urn:ihe:iti:2007:RegistryStoredQueryResponse</wsa:Action><wsa:RelatesTo>urn:uuid:6C0A7AC4D92351F45B1268908706961</wsa:RelatesTo></soapenv:Header><soapenv:Body><query:AdhocQueryResponse xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"><rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"><rim:ExtrinsicObject id="urn:uuid:5d57a8e7-fa67-4d08-bc88-d3fdd41036ba"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
mimeType="text/plain" isOpaque="false" home=""lid="urn:uuid:5d57a8e7-fa67-4d08-bc88-d3fdd41036ba"><!-- 省略 -- ><rim:ExternalIdentifier id="urn:uuid:5a7acd13-3ef7-46e7-8e80-a0af73fbe9d0"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
value="160.27.80.47.1.54"
home="" lid="urn:uuid:5a7acd13-3ef7-46e7-8e80-a0af73fbe9d0"
registryObject="urn:uuid:5d57a8e7-fa67-4d08-bc88-d3fdd41036ba"><rim:Name><rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="XDSDocumentEntry.uniqueId" /></rim:Name><rim:Description /><rim:VersionInfo versionName="1.1" /></rim:ExternalIdentifier></rim:ExtrinsicObject><rim:ExtrinsicObject id="urn:uuid:427a40e6-7214-425a-a020-ed83192b88ac"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
mimeType="text/plain" isOpaque="false" home=""lid="urn:uuid:427a40e6-7214-425a-a020-ed83192b88ac"><!-- 省略 -- ><rim:ExternalIdentifier id="urn:uuid:df573256-0d32-44bc-8954-be0123b5fba7"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
value="160.27.80.47.1.55"
home="" lid="urn:uuid:df573256-0d32-44bc-8954-be0123b5fba7"
registryObject="urn:uuid:427a40e6-7214-425a-a020-ed83192b88ac"><rim:Name><rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="XDSDocumentEntry.uniqueId" /></rim:Name><rim:Description /><rim:VersionInfo versionName="1.1" /></rim:ExternalIdentifier></rim:ExtrinsicObject></rim:RegistryObjectList></query:AdhocQueryResponse></soapenv:Body></soapenv:Envelope>

図 B-21 レジストリからの検索結果

35

地域医療連携情報システム構築ハンドブック 201１ 附属書（４）文書の取得 [ITI-43]
コンシューマからリポジトリへ出される文書取得要求メッセージの例を図 B-22 に、このメッセージ例に対する結果として得られる文書取得結果メッセージの例を図 B-23 にそれぞれ示す。文書取得要求メッセージと文書取得結果メッセージは両方とも
MTOM/XOP 形式を利用した SOAP メッセージであることに注意すること。
文書取得要求では、取得したい文書があるリポジトリの uniqueId（repositoryUniqueId）と取得したい文書の uniqueId をメッセージ内で指定する（図 B-22 の下部にあるDocumentRequest タグを参照）
POST /tf6/services/xdsrepositoryb HTTP/1.1
Content-Type: multipart/related;boundary=MIMEBoundaryurn_uuid_6C0A7AC4D92351F45B1268908711218;
type="application/xop+xml";
start="<0.urn:uuid:6C0A7AC4D92351F45B1268908711219@apache.org>";
start-info="application/soap+xml"; action="urn:ihe:iti:2007:RetrieveDocumentSet"
User-Agent: Axis2
Host: jiji:9080
Transfer-Encoding: chunked--MIMEBoundaryurn_uuid_6C0A7AC4D92351F45B1268908711218
Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:6C0A7AC4D92351F45B1268908711219@apache.org><?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:To>http://elektra:9080/tf6/services/xdsrepositoryb</wsa:To><wsa:MessageID>urn:uuid:6C0A7AC4D92351F45B1268908711215</wsa:MessageID><wsa:Action>urn:ihe:iti:2007:RetrieveDocumentSet</wsa:Action></soapenv:Header><soapenv:Body><RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ihe:iti:xds-b:2007
file:/Users/bill/ihe/Frameworks/ITI-4/XDS.b/schema/IHE/XDS.b_DocumentRepository.xsd"><DocumentRequest><RepositoryUniqueId>1.19.6.24.109.42.1.5</RepositoryUniqueId><DocumentUniqueId>160.27.80.47.1.54</DocumentUniqueId></DocumentRequest>

要求するドキュメントの情報</RetrieveDocumentSetRequest></soapenv:Body></soapenv:Envelope>--MIMEBoundaryurn_uuid_6C0A7AC4D92351F45B1268908711218--

図 B-22 リポジトリへの文書取得要求メッセージ

それに対して文書取得結果メッセージには、要求された文書本体が含まれる。図36

地域医療連携情報システム構築ハンドブック 201１ 附属書

B-23 の文書取得結果メッセージにおいて、SOAP メッセージの Body 部にDocumentResponse タグがあるが、これは取得した文書の情報が記述される。文書本
体は SOAP メッセージの添付データとして取り扱われる。DocumentResponse タグと文書本体は、DocumentResponse タグ内にある Document タグで対応付けられる。
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: multipart/related;boundary=MIMEBoundaryurn_uuid_D93C36CAA0149E1BB01268908713305;
type="application/xop+xml";
start="0.urn:uuid:D93C36CAA0149E1BB01268908713306@apache.org";
start-info="application/soap+xml"; action="urn:ihe:iti:2007:RetrieveDocumentSetResponse"
Transfer-Encoding: chunked
Date: Thu, 18 Mar 2010 10:38:32 GMT--MIMEBoundaryurn_uuid_D93C36CAA0149E1BB01268908713305
Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:D93C36CAA0149E1BB01268908713306@apache.org><?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:Action>urn:ihe:iti:2007:RetrieveDocumentSetResponse</wsa:Action><wsa:RelatesTo>urn:uuid:6C0A7AC4D92351F45B1268908711215</wsa:RelatesTo></soapenv:Header><soapenv:Body><xdsb:RetrieveDocumentSetResponse xmlns:xdsb="urn:ihe:iti:xds-b:2007"><rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success" /><xdsb:DocumentResponse><xdsb:RepositoryUniqueId>1.19.6.24.109.42.1.5</xdsb:RepositoryUniqueId><xdsb:DocumentUniqueId>160.27.80.47.1.54</xdsb:DocumentUniqueId><xdsb:mimeType>text/plain</xdsb:mimeType><xdsb:Document><xop:Include href="cid:1.urn:uuid:D93C36CAA0149E1BB01268908713308@apache.org"
xmlns:xop="http://www.w3.org/2004/08/xop/include" /></xdsb:Document></xdsb:DocumentResponse>

取得したドキュメントの情報</xdsb:RetrieveDocumentSetResponse></soapenv:Body></soapenv:Envelope>--MIMEBoundaryurn_uuid_D93C36CAA0149E1BB01268908713305
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID: <1.urn:uuid:D93C36CAA0149E1BB01268908713308@apache.org>
This is my document.
It is great!
--MIMEBoundaryurn_uuid_D93C36CAA0149E1BB01268908713305--

図 B-23 リポジトリからの文書取得結果

37

取得した
ドキュメント
本体

地域医療連携情報システム構築ハンドブック 201１ 附属書

B.5 各アクタの設置形態
XDS に基づく地域医療連携システムを構築する場合には、定義されている各アクタをどのように配置するかが問題となる。各アクタの配置形態についてはさまざま考えられるが、ここでは例として以下のケースを取り上げる。
なお、XDS の各アクタがどのように配置されようとも、取り扱う患者情報は外部漏洩や不正利用などがないように安全に管理されなければならず、また安全に管理されるようシステム構築がなされなければならない。このため厚生労働省がいくつかのガイドラインを作成し、遵守を求めている。
・ケース 1（図 B-24）
ソース、リポジトリ、コンシューマは各医療機関にて維持管理し、レジストリは第三者機関に１つだけ設置して各医療機関からのメタデータを集中管理する。ここで第三者機
関とは医療機関だけでなく、行政機関などが開設したデータセンター、ならびに医療機関などの委託をうけて情報を保管する民間のデータセンターをも指す。

図 B-24 ケース 1・ケース 2：（図 B-25）
ソース、コンシューマは各医療機関にて維持管理し、レジストリ、リポジトリは第三者機関にそれぞれ１つ設置し管理するもの。各医療機関からの文書本体及びメタデータはこの第三者機関において集中管理される。なお、ここで言う第三者機関はケース１と同じ。

38

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 B-25 ケース２

B.6 各アクタが持つべき機能
B.6.1 ドキュメントソース
ドキュメントソース（ソース）が関連するトランザクションは表 B-15 の通りである。
表 B-15 ソースが関連するトランザクション
トランザクション

ソース/ターゲット

Provider And Register Document Set-b [ITI-41]

ソース

表 B-15 のトランザクションに対応するためにソースに実装する機能として、以下の機能（１）～（３）がある。このうち（１）は必須の機能である。
（１）文書の登録（必須）１つ、あるいは複数の文書がソースからレジストリ、リポジトリへ登録できるようにする。そのためには以下の項目が必要となる。
・登録する文書の選択
・メタデータの作成
・インタフェース
リポジトリに対して、MTOM/XOP 形式の SOAP メッセージで文書とそのメタデータが送信でき、かつリポジトリからの返信メッセージが受信できるインタフェース。
（２）文書間関係の定義
B.3（５）で説明した文書の関連が定義できるようにする。これを実現するには以下の項目ができる機能が必要である。
・新規文書を、既に登録済みの文書に対する差し替え（RPLC）、添付（APND）、変換（XFRM）、あるいは変換の上差し替え（XFRM_RPLC）として登録

39地域医療連携情報システム構築ハンドブック 201１ 附属書・既に登録済みの２つの文書に、差し替え（RPLC）、添付（APND）、変換（XFRM）、あるいは変換の上差し替え（XFRM_RPLC）という関係を定義する
・新規に登録する文書、あるいは既に登録済みの文書に電子署名を付与する。
ただし、既に登録済みの文書に対して文書間関係を定義する場合は、登録済み文書のメタデータ（ドキュメントエントリ）にレジストリが付与した entryUUID 値がソース側で必要となる。この entryUUID をレジストリから取得する場合、さらに・ドキュメントエントリの検索機能が必要となるかもしれない。これはコンシューマにおいて実装されるメタデータの検索機能と同じものである。
（３）フォルダの管理
文書の管理・取りまとめるために、フォルダを登録、管理できるようにする。これを実現
するには、・フォルダの新規登録（メタデータの作成を含む）
・フォルダへの文書追加ができる機能が必要である。
ただし、既に登録済みのフォルダに文書を追加する場合は、登録済みフォルダのメタ
データにレジストリが付与した entryUUID 値がソース側で必要となる。この entryUUID
をレジストリから取得する場合、さらに・フォルダの検索機能が必要となるかもしれない。これはコンシューマにおいて実装されるメタデータの検索機能と同じものである。
B.6.2 ドキュメントリポジトリ
ドキュメントリポジトリ（リポジトリ）に関連するトランザクションは表 B-16 の通りである。
表 B-16 リポジトリに関連するトランザクション
トランザクション

ソース/ターゲット

Provider And Register Document Set-b [ITI-41]

ターゲット

Register Document Set-b [ITI-42]

ソース

Retrieve Document Set [ITI-43]

ターゲット

表 B-16 のトランザクションに対応するためにリポジトリに実装する機能として、以下の機能が必要である。

40

地域医療連携情報システム構築ハンドブック 201１ 附属書（１）文書の保存
トランザクション［ITI-41］に従いドキュメントソースから送られてくる登録要求メッセージ
から、文書を取り出して保存する。これを実現するには、以下の機能を実装する。
なお、登録要求メッセージにサブミッションセット、フォルダとアソシエーションだけ含まれている場合は以下の機能は実行しなくてもよい。
・インタフェース。
ソースからの MTOM/XOP 形式の SOAP メッセージが受信でき、かつソースに対して返信メッセージが送信できるインタフェースが必要。登録要求メッセージから文書本体を抽出
・ドキュメントエントリの uniqueId の検証
リポジトリでは、抽出文書とそのドキュメントエントリに含まれる uniqueId 値とを対応付けて保存する。そのため、uniqueId が本当にユニークであるかを検証する必要がある。
・サブミッションセットの sourceId の検証
ソースからのアクセスを制限している場合は、登録要求メッセージがアクセスを許可したソースからのものかを検証する必要がある。その場合、sourceId 値はソース固有のID が設定されているので、これをチェックする。
・抽出文書の保存
抽出文書とそのドキュメントエントリに含まれる uniqueId 値とを対応付けて保存する。文
書の保存には、ファイルとして保存する場合、データベースツールを利用する場合などがある。なお、文書のハッシュ値及びサイズを計算しておく。これらは次の（２）で使用する。
（２）メタデータの登録
上記（１）で文書抽出後、トランザクション[ITI-42]に従い、登録要求メッセージに含まれるメタデータをレジストリへ送る。これを実行するために以下の機能が必要となる。
・文書情報をメタデータへ追加
リポジトリに保存する文書に関係する情報を、保存文書のドキュメントエントリの属性値として追加する。追加対象となる属性は表 C－１７の通り。なおリポジトリそのものを表す固有 ID をあらかじめ決めておかなければならない。

41

地域医療連携情報システム構築ハンドブック 201１ 附属書

表 B-17 追加対象となる属性
ドキュメントエントリ
の属性値

必要性

設定値

hash

R

文書のハッシュ値

size

R

文書をファイル化した時のサイズ

RepositoryUniqueId

R

文書を保存するリポジトリに割り当てられた固有のID

URI

O

文書へアクセス可能なURI

凡例 R：必須 O：任意

・インタフェース
レジストリに対して、SOAP メッセージ（SIMPLE SOAP）でメタデータが送信でき、かつレ
ジストリからの返信メッセージが受信できるインタフェースが必要。
（３）文書取得要求に対する対応
トランザクション[ITI-43]に従い、コンシューマからの文書取得要求メッセージを受け取ると、リポジトリはその要求に応じた文書をコンシューマへ送る。機能としては以下が必要となる。
・インタフェースコンシューマからの文書取得要求メッセージが取得でき、コンシューマへ要求に応じた文書を送ることができる。送受信メッセージとして MTOM/XOP 形式の SOAP メッセージを取り扱えるようにすること。
・要求に応じた文書を用意する
トランザクション[ITI-43]に従う場合、文書取得要求メッセージには、取得したい文書の情報として、文書のドキュメントエントリの属性である uniqueId が含まれている。リポジト
リは uniqueId に合致する文書を取り出し、コンシューマへ送る準備をする。
（４）エラー処理
リポジトリにおいてエラーが発生した場合は、呼び出し元（ソース、コンシューマ）にエラーメッセージを送る。XDS ではどの場合にどのようなエラーを発生させるかが決まっている。エラーについての詳細は IHE-TF-3 の 4.1.13 を参照のこと。
トランザクション[ITI-41][ITI-42]におけるドキュメント登録において、レジストリ側でエラーが発生した場合はエラーメッセージをレジストリから受け取る。このとき、リポジトリでは保存したドキュメント本体を削除したうえで、ソースへエラーメッセージを送る。
B.6.3

ドキュメントレジストリ

ドキュメントレジストリ（レジストリ）に関連するトランザクションは表 B-18 の通りである。
42

地域医療連携情報システム構築ハンドブック 201１ 附属書

表 B-18 レジストリに関連するトランザクション
トランザクション

ソース/ターゲット

Register Document Set-b [ITI-42]

ターゲット

Registry Stored Query [ITI-18]

ターゲット

Patient Identity Feed [ITI-8] *ターゲット

Patient Identity Feed HL7v3 [ITI-44] *ターゲット

注：本節では*印のトランザクションにかかわる処理については記述しない

表 B-18 のトランザクションに対応するためにレジストリに実装する機能として、
以下の機能が必要である。ただし本節では、Patient Identity Feed に関する
[ITI-8]及び[ITI-44]に対する機能は触れない。
（1）メタデータの登録
トランザクション[ITI-42]に従い、レジストリが登録要求メッセージを受け取ると、これに含まれるメタデータをレジストリに保存する。メタデータは形式、内容が検証され、XDS で定義された形式に従っていると判断されたものが保存される。これを実行するために以下の機能が必要となる。
・インタフェース
リポジトリからの登録要求メッセージを含む SOAP メッセージ（SIMPLE SOAP）
が受け取れるようにする。またリポジトリへの返信メッセージが送れるようにする。
・メタデータの検証
登録要求メッセージに含まれるメタデータの形式が IHE-TF-3 の 4.1.7（ドキュメントエントリ）、4.1.8（サブミッションセット）、及び 4.1.9（フォルダ）で定義された形式と合致していることを確認する。
またメタデータの各属性値には、IHE-TF-3 の 4.1.10 で定義されているような制約があるので、各属性値が制約を満たしていることを確認する。
・メタデータの属性追加
レジストリ側でメタデータの属性を新規追加する。新規追加の対象となる属性を表 B-19 に示す。

43

地域医療連携情報システム構築ハンドブック 201１ 附属書

表 B-19 追加対象となる属性
メタデータ
の種類

属性

備考

ドキュメントエントリ

availabilityStatus

新規登録時に「urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved」とする。

entryUUIDUUID値で指定する。UUIDの形式はIHE-TF-3の4.1.7にある
Table4.1-3を参照

homeCommunityId

オプションだが、XCAを利用して複数コミュニティを連携させる場合は必須

availabilityStatus

新規登録時に「urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved」とする。

entryUUIDUUID値で指定する。UUIDの形式はIHE-TF-3の4.1.7にある
Table4.1-3を参照

homeCommunityId

オプションだが、XCAを利用して複数コミュニティを連携させる場合
は必須

lastUadateTime

新規に登録された時の時間

フォルダ

サブミッショ availabilityStatus
ンセット

新規登録時に「urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved」とする。

entryUUIDUUID値で指定する。UUIDの形式はIHE-TF-3の4.1.7にある
Table4.1-3を参照

homeCommunityId

オプションだが、XCAを利用して複数コミュニティを連携させる場合
は必須

・患者 ID の検証
ドキュメントエントリに含まれる患者 ID が、該当のコミュニティにおいて有効かどうかを調べる。
・登録データのアトミック性の保証
登録要求メッセージに含まれるすべてのメタデータが無事登録できた場合は、登録成功（Success）の返信メッセージをリポジトリへ送る。
しかし、登録要求メッセージに含まれるメタデータのうち、エラー発生などで一つでも登録に失敗した場合は、その登録要求メッセージに含まれるメタデー
タで登録に成功したものをすべて削除し、エラーメッセージをリポジトリへ送る。エラーについては後述のエラー処理を参照のこと。すなわち、この場合は登録要求そのものをなかったものとすることになる。
・文書の置き換え登録要求メッセージに文書の置き換え（RPLC、XFRM_RPLC）を含む場合は、置き換えられる文書のドキュメントエントリが登録済みであること、そのavailabilityStatus が Approved であることを確認した上で、置き換えられるドキュメントエントリの availabilityStatus を Duplicated に変更する。
・フォルダの患者 ID の検証
フォルダのメタデータ属性である patientId の値とフォルダに属するドキュメ
44

地域医療連携情報システム構築ハンドブック 201１ 附属書

ントエントリのメタデータ属性 patientId の値が一致することを確認する。
・MIME タイプの検証
ドキュメントエントリのメタデータ属性 mimeType で指定されている MIME タイプが XDS アフィニティドメインで指定されているものであるかを調べる。
・フォルダの属性 lastUpdateTime の維持管理
既に登録されているフォルダに新規にドキュメントエントリを追加した場合、フォルダのメタデータ属性 lastUpdateTime が追加した時間に再設定する。
・フォルダに追加する文書の患者 ID の検証
既に登録されているフォルダに新規にドキュメントエントリを追加する場合、フォルダの patientId とドキュメントエントリの patientId が一致することを確認する。
・コード数の確認
メタデータ属性の中には、複数設定できるものもあれば（例：ドキュメントエ
ントリの author、eventCodeList など）、一つのみ設定できるもの（例：ドキュメントエントリの classCode）もある。属性が適切な数量だけ設定できているかどうかを調べる。
・メタデータの保存登録要求メッセージに含まれるメタデータを適正に保存する。登録要求メッセージに複数のドキュメントエントリが含まれていても同様である。
（２）検索要求に対する対応
トランザクション[ITI-18]に従って、コンシューマ（場合によってはソース）
からの検索要求メッセージを受け取ると、レジストリはそのメッセージで指定されているストアドクエリに従い、レジストリが保存しているメタデータの中から、検索要求メッセージに含まれる検索条件に沿ったメタデータを捜す。
ストアドクエリの種類は表 B-4 を参照のこと。なおストアドクエリの種類ごとにコンシューマで設定可能な検索条件が決まっている。詳細な説明は ITI-TF-2aの 3.18.4.1.2.3.6.1 を参照のこと。
（３）エラー処理
レジストリにおいてエラーが発生した場合は、呼び出し元にエラーメッセージを送る。
XDS ではどの場合にどのようなエラーを発生させるかが決まっている。エラーについての詳細は ITI-TF-3 の 4.1.13 を参照のこと。
上記（１）で述べたようにトランザクション[ITI-42]の実行過程で発生した場合は、登録要求そのものをなかったものとする必要があるため、以下の処理を

45

地域医療連携情報システム構築ハンドブック 201１ 附属書行う。
・登録要求メッセージに含まれるメタデータで登録に成功したものをすべて削除する。
・lastUpdateTime を更新していた場合は元の時間に戻す。
・文書置き換え処理を実行した場合は、Duplicated に置き換えられたドキュメ
ントエントリの availabilityStatus を元の Approved に戻す。
B.6.4

ドキュメントコンシューマ

ドキュメントコンシューマ（コンシューマ）に関連するトランザクションは表B-20 の通りである。
表 B-20 コンシューマに関連するトランザクション
トランザクション

ソース/ターゲット

Registry Stored Query [ITI-18]

ソース

Retrieve Document Set [ITI-43]

ソース

表 B-20 のトランザクションに対応するためにレジストリに実装する機能として、
以下の機能が必要である。
（１）メタデータ検索
メタデータ検索はトランザクション[ITI-18]に従い、ストアドクエリにより行う。レジストリがどのストアドクエリをサポートしているかを調べた上で、以下の機能を実装する。なお、以下の機能はいずれも GUI を利用してメッセージ
作成や結果の提示を行うことになる。
・検索要求メッセージ作成
ストアドクエリと検索条件を設定し、これをレジストリへ送る。なおストアド
クエリの種類ごとに設定可能な検索条件が決まっている。詳細な説明は
ITI-TF-2a の 3.18.4.1.2.3.6.1 を参照のこと。
・検索結果提示
レジストリからの返信メッセージから検索結果として含まれるメタデータを取り出し、利用者に提示する。検索結果の概要を一覧表で示す一覧表示、及び一つのメタデータの詳細を表示する詳細表示の 2 種類が考えられる。
・インタフェース
レジストリのと間で SOAP メッセージ（SIMPLE SOAP）の送受信ができるようにする。

46

地域医療連携情報システム構築ハンドブック 201１ 附属書（２）文書取得
トランザクション[ITI-43]に従い、文書本体を取得する。そのために以下の機能が必要となる。
・文書取得要求メッセージ作成
文書取得要求メッセージを作成し、これをリポジトリへ送る。文書取得要求メッセージは取得したい文書のドキュメントエントリに含まれる属性 uniqueId、
mimeType 及び repositoryUniqueId で構成される。
・取得文書の提示
文書取得要求により、リポジトリから得られた文書を利用者に提示する。
・インタフェース
リポジトリへの文書取得要求メッセージを MTOM/XOP 形式の SOAP メッセージで送信できるようにする。またリポジトリから文書が MTOM/XOP 形式の SOAP メッ
セージで送られてくるので、これを取り扱えるようにする。
B.7 XDS における最近の動向
前節までは、XDS の基本的なアクタであるソース、リポジトリ、レジストリ及びコンシューマについて説明した。しかし最近になって、XDS 統合プロファイル
で新しいアクタやトランザクションが、また XDS を補完する新しい統合プロフ
ァイルがそれぞれ提案されている。
本節ではまず、今後利用すれば有益であると思われるアクタとして・オンデマンドドキュメントソース
・ドキュメントアドミニストレータを紹介する。これらに関連する新しいトランザクションとして、・Register On-Demand Document Entry[ITI-61]
・Update Document Set [ITI-57]
・Delete Document Set [ITI-62]がある。
次に、既存のアクタに関連する新しいオプションとして、・非同期型 Web サービス交換（Asynchronous Web Service Exchange）を紹介する。
さらに本節では、XDS のメタデータ検索に関する新しい統合プロファイルとして、・MPQ（Multi-Patient Query）
を紹介する。MPQ では、レジストリとリポジトリの間に新しいトランザクション
Multi-Patient Stored Query[ITI-51]が定義される。
以上新しく定義されたものを含めた、アクタおよびトランザクションの関係図

47

地域医療連携情報システム構築ハンドブック 201１ 附属書を図 B-26 に示す。

Retrieve Document Set[ITI-43]

患者IDソース

オンデマンドドキュメントソース

ドキュメントアドミニストレータ

Register
On-Demand
Document
Entry [ITI-61]

Update Document Set[ITI-57]

Patient Identity Feed [ITI-8]
Patient Identity Feed HL7v3[ITI-44]
Multi-Patient Stored
Query [ITI-51]

ドキュメント
レジストリ

Delete Document Set[ITI-62]

Register Document
Set-b [ITI-42]

RegistryStored Query[ITI-18]

ドキュメントソース
既存のアクタProvide&Register
Document Set-b[ITI-41]

新規アクタ

図 B-26

RegistryStored Query[ITI-18]

ドキュメントコンシューマドキュメントリポジトリ

Retrieve Document Set[ITI-43]

既存のトランザクション

新規のトランザクション

XDS におけるアクタ・トランザクション

B.7.1 オンデマンドドキュメントソース
オンデマンドドキュメントソース（On-Demand Document Source）は、以下の処
理を行う
患者の医療データに対するメタデータとして「オンデマンドドキュメントエン
トリ（On-Demand Document Entry）」を作成してドキュメントレジストリへ登録する（トランザクション[ITI-61]）。
コンシューマから文書取得要求（[ITI-43]）をオンデマンドドキュメントソー
スが受け取ると、「オンデマンドドキュメント」を作成してコンシューマへ送る（[ITI-43]）
ここで「オンデマンドドキュメントエントリ」は、患者の医療情報が格納されているデータベースから、どの患者の、どのような種類の医療データ（コンテンツ）が提供可能であるかを記述するメタデータである。
「ドキュメントエント
リ」は文書のインデックス情報であり、リポジトリへ登録する文書の存在が前提であるが、「オンデマンドドキュメントエントリ」はそのような文書は存在しない。

48

地域医療連携情報システム構築ハンドブック 201１ 附属書その代わりオンデマンドドキュメントソースは、コンシューマから文書取得要求を受け取ると、文書取得要求に対応するオンデマンドドキュメントエントリに記述されたコンテンツを医療情報データベースから動的に収集して、オンデ
マンドドキュメントと呼ばれる「文書」を作成し、これをコンシューマへ送る。
コンテンツの内容は時間の経過とともに変化するものもあることを考えると、
この「文書」はコンシューマからの文書取得要求を受け取った時点での最新のコンテンツから構成される。
B.7.2 ドキュメントアドミニストレータ
レジストリに登録されているメタデータの更新（[ITI-57]）及び削除（[ITI-62]）を実行する。更新及び削除の対象となるメタデータはストアドクエリ（[ITI-18]）を利用して取得する。以下本アクタで行う処理として、トランザクション単位
で取り上げる。詳細は文献[]を参照のこと。
・メタデータの更新（Update Document Set[ITI-57]）
以下の処理を行う。
・ドキュメントエントリ、フォルダの内容の更新
・ドキュメントエントリ、フォルダ、アソシエーションの AvailabilityStatusの更新
・新しいアソシエーションの登録
・メタデータの削除（Delete Document Set[ITI-62]）
ストアドクエリを利用して削除したいメタデータの entryUUID を取得し、ebXML
Redgistry Services and Protocols(ebXML RS) ver.3 で定義されている
RemoveObjectsRequest をレジストリへ送信する。
B.7.3

非同期型 Web サービス交換

XDS の各トランザクションは同期型の Web サービス交換に基づいている。同期型
Web サービスでは、あるトランザクションに基づいて一つのアクタ A から別のア
クタ B へリクエストを送信した場合、A は B からのレスポンスが帰ってくるまで他の処理を行わず待機する。従って、A は B からのレスポンスがないと待たされることになる。
これに対して、最近 XDS の各アクタを実装する際のオプションとして、非同期型の Web サービス交換の実装がサポートできるようになった。非同期型の Web
サービス交換では、一つのアクタ A からあるトランザクションに基づいたリク
エストを別のアクタ B に送信した場合、A は B からのレスポンスが帰ってくるまでの間でも他の処理が実行でき、かつ B からのレスポンスを受け取った時点で49

地域医療連携情報システム構築ハンドブック 201１ 附属書

レスポンスの受信処理を実行することができる。
非同期型 Web サービス交換は XDS プロファイルだけでなく、XCA 及び XCPD においても利用可能である。特に XCA と XCPD での応答ゲートウェイ（Responding
Gateway）では非同期型 Web サービス交換のサポートが必須となっている。
非同期型 Web サービス交換の詳細については、文献[1]の volume 2x,Appendix Vを参照のこと。
B.7.4

統合プロファイル MPQ

トランザクション Registry Stored Query[ITI-18]では、各ストアドクエリで一度に取り扱えるのは一人の患者に対するメタデータ検索であって、一度に複数の患者について扱うことはできない。これに対して統合プロファイル MPQ（Multi-Patient Query:複数患者検索）では、一度に複数の患者に対するメタデータを検索することを可能とし、そのためのトランザクションとしてMulti-Patient Stored Query[ITI-51]が定義されている。
このトランザクションに対応したストアドクエリとして以下のものがある。
・FindDocumentsForMultiplePatients・FindFoldersForMultiplePatients
これらのストアドクエリは[ITI-18]での FindDocuments と FindFolders を拡張したものである。詳しくは文献[1]の volume 2b を参照のこと。
参考文献[1] IHE IT Infrastructure Technical Framework, volume 1, 2a, 2b, 2x, 3,
Rev.8, August 19, 2011[2] IHE IT Infrastructure Technical Framework Supplement: On-Demand
Documents, Trial Implementation, Rev.1.2, August 19, 2011[3] IHE IT Infrastructure Technical Framework Supplement: XDS Metadata
Update, Trial Implementation, Rev.1.2, August 19, 201150

地域医療連携情報システム構築ハンドブック 201１ 附属書

附属書 C.

PIX/PDQ 概説

C.1 はじめにPIX/PDQ は、複数の患者 ID ドメインからの患者 ID の相互参照をおこなう方法と、患者
ID により患者の基本情報を取り込む方法を提供するものである。
具体的には、地域内の患者を一意に識別する地域患者 ID を管理することを目的として、患者基本情報のデータベースへの登録、更新、無効化を行い、患者基本情報問
い合わせへの応答を行う機能を提供する。
各医療機関からの患者 ID の対応付け（マッピング）を行い。患者名、生年月日などの基本情報から、患者 ID を知ることができる。
C.2 ユースケース（シナリオ）
適応領域は、分散環境にある多施設間および多職種間で、医療・介護・福祉などの情報を共有する場面で患者の ID 管理に適用される。
具体的には、EHR、PHR、地域医療連携システムなどの基盤の構成要素として使用される。
図 C-１のように、医療情報を施設間で共有する仕組みを考えると、患者 ID と患者基本情報を各施設から供給できる機能が必要になる。さらに、患者の ID は医療機関ごとにばらばらなため、患者 ID の照合と特定が必要となり、そのような機能を含む患者 ID 管理機能が必要になる。
医療情報にアクセスしたい各医療機関は、患者 ID の利用者（アクタ）を使って患者 ID
相互参照マネジャに問い合わせる。結果、自病院の患者 ID が医療連携するコミュニテ
ィ全体の中の ID（地域患者 ID）を知ることができる。

51

地域医療連携情報システム構築ハンドブック 201１ 附属書

地域連携センタ
患者ID相互参照マネージャ
患者ＩＤ提供M8354673993

L-716

患者IDソース

ドキュメントコンシューマ

14355
L-716

A87631

患者IDソース
M8354673993
患者ID 提供

患者IDの
問い合わせ
ドキュメント問い合
わせ (Pt ID)

電子カルテ A87631

患者ID相互参照
コンシューマドキュメントレジストリ

L-716
患者ID相互参照
コンシューマ

患者ID提供A87631
M8354673993

ドキュメント登録(Pt ID)

ドキュメントの読み出し

ドキュメント
リポジトリ

患者IDソース

ドキュメントソース

ドキュメントの提供
と登録

一般病院

中核病院
図 C-1．患者 ID の相互参照

C.3 PIX/PDQ 統合プロファイルの概要
図 C-２は、施設間の患者 ID に関する統合プロファイル PIX/PDQ に直接関与している
各 IHE アクタ及びトランザクションを図示している。
PIX/PDQ に関する機能要件を示す。実際の地域連携システム等に適用する場合は、それぞれの目的によって要求仕様は異なる。また、IHE の最新仕様などを確認して決定する必要がある。
PIX 統合プロファイルは、様々な規模の医療機関（病院、クリニックや開業医など）を対象とする。以下の相互やり取りを通じ、複数の患者 ID ドメインにまたがる患者 ID の相互参照をサポートする。
・患者 ID ソースから PIX Manager の患者 ID 情報の送信
・クエリ／レスポンスまたはアップデート通知によって相互参照の対象となる患者の ID リスト（複数可）へのアクセス機能
特定のアクタ間の上記のトランザクションを指定するもので、この統合プロファイルは、
特定の施設ポリシーや相互参照アルゴリズムを定義するものではない。その施設で適切であると考えられる任意の相互参照ポリシーおよびアルゴリズムと共に使用される柔軟性を維持しながら、単一のアクタにこれらの動作をカプセル化することによって、この52

地域医療連携情報システム構築ハンドブック 201１ 附属書

統合プロファイルは、必要な相互運用性を提供する。
図 C-2 は、このプロファイル（上記のような）の意図した範囲を示している。

Patient Identity
Source(患者IDソース)

Patient Identifier
Cross-reference
Consumer(PIXコンシューマ)

Patient Identity Feed[ITI-8]
Patient Identity Feed HL7V3[ITI-44]

PIX Query [ITI-9]
PIXV3 Query [ITI-45]

Patient
Demographics
Consumer(患者情報コンシューマ)

PDQ(Visit Query) [ITI-22]↓患者IDの問い合わせ

患者ID供給患者来院歴情報問い合わせ

PIX Update Notification [ITI-10]
PIXV3 Update Notification [ITI-46]

PDQ [ITI-21]
PDQ HL7V3 [ITI-47]↑更新通知

Patient Identifier
Cross-referenceManager(PIX マネジャ)

患者基本情報問い合わせ

Patient
Demographics
Supplier(患者情報サプライヤ)

図 C-２． PIX/PDQ 統合プロファイル

Patient Identifier
Cross-reference Domain

患者IDフィード、患者ID
レファレンス

患者IDドメインC
Patient Identifier
Cross-referenceManager

患者IDフィード

Patient Identity
Source内部ドメイント
ランザクション

患者IDフィード
患者ID相互参照

Patient Identity
Source内部ドメイント
ランザクション

Patient Identifier
Cross-reference
Consumer

他のIHEアクタ

患者ID相互参照

Patient Identifier
Cross-reference
Consumer

他のIHEアクタ

患者IDドメインA

患者IDドメインB

図 C-3 PIX プロセスフロー

53

地域医療連携情報システム構築ハンドブック 201１ 附属書

上記の図 C-3 は、患者 ID ドメイン及び患者 ID 相互参照ドメインという 2 種類の ID ドメ
インを示している。
患者 ID ドメインは、単一のシステム、または共通の ID スキーム（ID と、患者への割り当て処理）と患者 ID を発行する権限を共有する相互接続されたシステム群である。さらに、
患者 ID ドメインは、以下のプロパティをもつ。
・ドメイン特有の要件に沿って、どのように ID が定義され、管理されるかを記載したポリシーのセット。
・ドメイン内で ID に関連するポリシー管理を行う管理機関。
・患者 ID システムとして知られる単一のシステムで、患者関連オブジェクトのそれぞれのインスタンスに固有 ID を割当てたり、ID 特性情報を維持する。
・単一の患者 ID ソースアクタが同じ患者に複数の ID を与え、この事実を PIX Managerに通知する場合もあるが、理想的には、患者 ID ドメインの中において、ひとつの ID のみが特定の患者と固有に関連付けられるべきである。PIX Manager アクタが、これらの「重複」を含む相互参照 ID リストへのリクエストにどのように返答するかについては、ITI
TF-2a: 3.9.4.2.2.6 を参照。
・患者 ID 相互参照ドメイン内固有の割当機関として知られる「ID ドメイン識別子（Identifier Domain Identifier）」
・患者 ID ドメイン内の他のシステムは、自らが属するドメインの患者 ID ソース（システム）
により割当てられた ID に依存する。
患者 ID 相互参照ドメインは、PIX Manager アクタにより認識、管理されている患者 ID ド
メインのセットから成り立っている。PIX Manager アクタは、異なる患者 ID ドメイン間において、別名が使用されている ID リストの作成、保守、提供を行う。
患者 ID 相互参照ドメインにより、個別の ID ドメイングループ間の合意に関して、前提となっている以下の事項について、具体化が行われる。
・参加するドメイン間において、いかに患者 ID 相互参照が行われるかを記述したポリシーについて合意済み。
・これらのポリシーを管理するためのプロセスについて合意済み。
・これらのプロセスとポリシーを管理する機関について合意済み。
これらの前提はすべて、本プロファイル導入の成功に重要である。PIX 統合プロファイ
ルは、参加する患者 ID ドメインにおける制約を最小限にし、また、PIX Manager アクタ
内における患者 ID 相互参照ドメイン全体の運用制約のほとんどが集中化される。もし、54

地域医療連携情報システム構築ハンドブック 201１ 附属書

個別の ID ドメインが上記に示された点に合意できなければ、このプロファイルの導入は期待される結果をもたらさない可能性もある。
PIX Manager には、Patient Identity Source アクタからそこに提供される ID 情報の質の向上についての責任は無い。Patient Identity Source は PIX Manager に、高品質のデータを提供する義務があることが前提となっている。例えば、PIX Manager は、患者基
本情報について、単一の情報ソースを提供する責任はない。
ここでは、患者個人情報の質と管理、ID の完全性についての責任はそれぞれのPatient Identitiy Domain（Source アクタ）に残すことを意図している。複数の PIX Domainからレポートと表示情報を受信する際、これらのレポートや表示情報に名前の不一致が含まれることは避けられない。
PIX Consumer は、相互参照患者 ID のクエリを使用するか、相互参照の変更通知とク
エリトランザクションの両方を使用する可能性がある。通知を使用するにあたり、PIX
Consumer は、また、PIX Consumer が PIX Manager と同期していない可能性がある状況に対処するため、PIX Query トランザクションを使用することもある。
PIX 統合プロファイルは PIX Query トランザクション（ITI TF-2a: 3.9）を使用する際のポ
リシーを特定するものではない。
PIX 統合プロファイルと、施設マスター患者インデックス（eMPI）との関連についての議論は、ITI TF-1:5.4 節を参照のこと。
C.4 PIX
C.4.1 アクタとトランザクション
表 C-1 は、PIX プロファイルに直接関連する各アクタのトランザクションをまとめたものである。アクタがこの統合プロファイルをサポートしていると宣言するには、「R」で示される、
必須トランザクションを実行しなければならない。「O」で示されるトランザクションはオプ
ショナルである。PIX 統合プロファイルで定義され、アクタがサポートすることを選択できるオプションの全リストは、ITI TF-1: 5.2 に示されている。
表 C-1 MPI プロファイルのための PIX 統合－アクタとトランザクション
アクタ

Patient Identity Source

Patient Identifier Cross-reference

トランザクション

必須（R）／
オプショナル（O）

Vol.2内の節

Patient Identity Feed
(患者 ID フィード)[ITI-8]

R

ITI TF-2:3.8

Patient Identity Management（患者ID管理）[ITI-30]

O

ITI TF-2b: 3.30

PIX Query (PIX クエリ)[ITI-9]

R

ITI TF-2:3.955

地域医療連携情報システム構築ハンドブック 201１ 附属書

Consumer

PIX Update Notification(PIX アップデート通知)[ITI-10]

O

ITI TF-2a: 3.10

Patient Identifier Cross-referenceManager

Patient Identity Feed
(患者IDフィード)[ITI-8]

R

ITI TF-2a: 3.8

PIX Query (PIXクエリ)[ITI-9]

R

ITI TF-2a: 3.9

PIX Update Notification(PIXアップデート通知)[ITI-10]

R

ITI TF-2a: 3.10

C.4.2 オプション
PIX 統合プロファイルのために選択可能なオプションを、対応するアクタとともに表 C-2に示す。必要に応じて、オプション間の依存関係を注に示す。
表 C-2 PIX – アクタとオプション
アクタ

オプション

Vol＆節

Patient Identity Source

Pediatric Demographics

ITI TF-1: 5.2.1

Patient Identifier Cross-reference Manager

Pediatric Demographics

ITI TF-1: 5.2.1

Patient Identifier Cross-reference Consumer

PIXアップデート通知

ITI TF-2a: 3.10

・小児基本情報（Pediatric Demographics）
小児基本情報は、多くの小児のレコードを持つデータベースに一致するレコードを支援するために次の 6 つの追加の患者基本情報フィールドを利用する。
表 C-3 小児基本情報
理由

価値Mother’s Maiden Name項目

母親についての情報は、照合を行う際

真のポジティブな照合を簡単（母親の旧姓）に有効であるに作成できる

Patient Home Telephone

テレコムは、正しい世帯に一致するの

真のポジティブな照合を簡単（患者自宅電話番号）に役立つに作成できる

Patient Multiple Birth Indicator

双子、三つ子等 - この人が複数である

複数の偽ポジティブの一致を（患者の複数の出生インジケ

ことを示す

避けることができる

それらの複数の間で区別する。

複数の偽ポジティブの一致をータ）
Patient Birth Order（患者出生順位）

避けることができる

Last Update Date/Time, Last

複数の出生指標および出生順位が収

複数の偽ポジティブの一致をUpdate Facility

集されていないときも、厳密には患者避けることができる（最終更新の日付/時刻、

基本情報ではないこれらのフィール

最終更新施設）ドは、効果的に置き換えることができる。彼らは、間接的に訪問の情報を提供する。同じ日の施設訪問は、おそら
く一緒に医者に会った二人の子供を示すことがあり得る。

56

地域医療連携情報システム構築ハンドブック 201１ 附属書

C.4.3

プロセスフロー

図 C-4 PIX ワークフロー（施設内）図図 C-5 PIX ワークフロー（施設間）図57

地域医療連携情報システム構築ハンドブック 201１ 附属書C.4.4 eMPI との関係
PIX 統合プロファイルは、同じ患者に関連付けられた患者 ID の相互参照を使用することで、分散する患者 ID ドメインの統合を可能にする。この節では、このアプローチがいかに、マスター患者 ID（MPI）や施設 MPI（eMPI）システムの確立を必要とする環境に適合するかを述べる。eMPI は PIX 統合プロファイル実装のバリエーションと捉えられる場合もある。
MPI のコンセプトは幅広いものであるが、多くの場合マスター患者 ID ドメインの作成と関連付けられる。このようなマスタードメインは、マスタードメインに含まれている他の患者 ID ドメインと比べ、より幅広く適用が可能、あるいはより「施設レベル」であると捉えられている。このように、患者 ID ドメインを「マスター患者 ID ドメイン」に階層的に含むことは、様々なドメイン内の患者 ID とマスタードメイン内の患者 ID が相互参照する形となり、患者相互参照の 1 つの特別な事例と考えることができる。想定される 2 種類の設定について、以下の図 C-6 に示されている。
マスター患者インデックス

Patient Identity
Cross-referenceManager

Master （C) Patient
Identity Source
マスター患者
インデックス

患者IDドメインC（マスタードメイン）

患者IDドメインA

Master （C) Patient
Identity Source

患者IDドメインB

マスター患者インデックスには2件のドメインが含まれる

Patient Identity
Cross-referenceManager

患者IDドメインC（マスタードメイン）

患者IDドメインA

患者IDドメインB

3相互参照ドメインとして示される同様の設定

図C-6 PIXプロファイルとeMPIとの関係

上記の図 C-6 は、一般的な MPI で考えるマスター患者 ID ドメイン（ドメイン C）が、相互参照の概念で考えた場合、患者 ID ドメインのひとつに過ぎないということを示している。
「マスタードメイン」内に、Clinical Data Repository などの施設全体で使用されるシステ
ムを配置するという決定は、単に設定に関する選択であるといえる。さらに、このような設定においては、患者ドメイン A 内のいかなるシステムも、ドメイン A の患者 ID の管理を行うだけでなく、ドメイン C の ID も認識していることが前提となっている場合がある。
PIX 統合プロファイルにおいて、特定のシステムが複数のドメイン間で運営されるように
58

地域医療連携情報システム構築ハンドブック 201１ 附属書

設計および設定されることは、設定に関する選択である。このため、MPI（楕円で示されている）と広く呼ばれる構成要素は、実際は Patient Identity Source アクタ（ADT）と PIX
マネジャとの組み合わせである。
PIX 統合プロファイルは明確な MPI を設置するような環境とも共存することができ、より柔軟に拡張できるアプローチを提供する。特に、他のドメインを含むようなマスタードメ
インの作成が必要ではない場合（すなわちドメインの単純な連合であり、どのドメインも実際にはマスターでない）など、他にも様々な設定を設置することができる。
C.5 PDQ
C.5.1 アクタとトランザクション
図 C-7 は、PDQ 統合プロファイルに直接関連するアクタと、アクタ間で関連するトランザクションを示している。Patient ID Cross-referencing などに参加しているために、間接的に関連している他のアクタはここでは示されていない。

Patient Demographics
Supplier

患者基本情報クエリ[ITI-21]↑↑患者基本情報と来院
情報クエリ[ITI-22]

Patient Demographics
Consumer

図 C-7 PDQ プロファイルアクタ図表 C-3 は、PDQ 統合ファイルに直接関連する各アクタのトランザクションをまとめたものである。アクタが PDQ 統合プロファイルをサポートしていると宣言するためには、「R」で示される、必須トランザクションを実行しなければならない。「O」で示されるトランザクシ
ョンは、オプショナルである。この統合プロファイルで定義され、アクタがサポートすることを選択できるオプションの全リストは、ITI TF-1: 8.2 に示されている。
表 C-３ PDQ 統合プロファイル － アクタとトランザクション
アクタ

トランザクション

59

必須（R）／

Vol.2内の節地域医療連携情報システム構築ハンドブック 201１ 附属書

オプショナル（O）
Patient Demographics
Consumer

Patient Demographics
Supplier

Patient Demographics Query[ITI-21](患者基本情報クエリ)

R

ITI TF-2a: 3.21

Patient Demographics and Visit
Query[ITI-22](患者基本情報と受診情報クエリ)

O

ITI TF-2a: 3.22

Patient Demographics Query[ITI-21](患者基本情報クエリ)

R

ITI TF-2a: 3.21

Patient Demographics and Visit
Query[ITI-22](患者基本情報と受診情報クエリ)

O

ITI TF-2a: 3.22

C.5.2 オプション
PDQ 統合プロファイルのために選択可能なオプションを、対応するアクタとともに表C-4 に示す。
表 C-４ Patient Demographics Query - アクタとオプション
アクタ
Patient Demographics Consumer

Patient Demographics Supplier

オプション

Vol＆節

Patient Demographics and Visit Query

ITI TF-2a: 3.22

Pediatric Demographics

ITI TF-1: 8.2.2

Patient Demographics and Visit Query

ITI TF-2a: 3.22

Pediatric Demographics

ITI TF-1: 8.2.2

60

地域医療連携情報システム構築ハンドブック 201１ 附属書

附属書 D.

ATNA, CT 概説

本附属書では、システム構築時に必要となるセキュリティ基盤について技術的な観点でまとめる。なお、セキュリティ環境の構築時のポリシーや考え方については本編 5 章「ネットワーク基盤」を参照されたい。また、具体的な監査証跡ログの形式については
D.5 に記載する。
D.1

セキュリティ基盤概要

地域連携システム構築にあたり、構築するシステムのセキュリティポリシーに基づいて、どのようなメカニズムを利用してセキュリティを実現するか検討する必要がある。IHE にはこのような検討点を解決するために、IT インフラストラクチャ分野で、いくつかの業務
シナリオを提供している。
こ こ で は 、 監 査 証 跡 ロ グ に つ い て 記 載 さ れ て い る ATNA(Audit Trail and Node
Authentication)、文書・画像・監査証跡ログ等の情報を正しく集めるために時刻を一致させておくことができる CT(Consistent Time)を紹介する。
IHE の ITI 領域では、この他に、登録した文書や画像に対するアクセスコントロールを実現している BPPC(Basic Patient Privacy Consents) 、利用者認証に活用 できる
EUA(Enterprise User Authentication), XUA(Cross-Enterprise User Assertion)などの統合プロファイルも提案されている。業務分析を行い、業務シナリオに合致した統合プ
ロファイルがあれば利用することをお勧めする。
D.2 統合プロファイル各論
D.2.1 ATNA
（1) 統合プロファイル概要① 位置づけと背景
ATNA 統合プロファイルは IHE IT Infrastructure 領域の１つとして登録されており、2011 年 10 月現在の最新バージョンは、Revision 8.0（201１年 8 月 19 日版）である。
② プロファイル概要
ATNA 統合プロファイルは、次の４つの項目の実現を目的とする。
1) ユーザへの説明責任（監査証跡）：組織のセキュリティ管理者による監査に基づく、安全性に関する領域内のポリシーの遵守の評価、保護すべき PHI(健康情報）に対する不適切な生成、アクセス、修正、削除の発見、
2) アクセス制御：ネットワークアクセスをノード間に制限し、各ノードに対して認可されたユーザにアクセスを制限する方法でのアクセス制御、
3) 集中監査記録リポジトリ：全ての IHE アクタから、監査証跡リポジトリへの監査記録の61

地域医療連携情報システム構築ハンドブック 201１ 附属書転送が必要、
4) PHI（Protected Health Information）の完全性：PHI の有効期間とその過程におけるデータの完全性の追跡。
ATNA 統合プロファイルは、次のような条件を元に検討されている。
1)“Secure Domain”に参加しているシステムは、ATNA プロファイルのセキュリティノード
アクタとトランザクションを実装している。
2) セキュアノード上の全てのアプリケーションはこれらが IHE アクタであるか否かにかかわらず ATNA の要求に従う。
3) ATNA 統合プロファイルは、ネットワーク攻撃やウィルス汚染などの、他のセキュリテ
ィ要求については言及しない。
4) IHE は転送時の暗号の使用は要求しない。他の認可されたセキュアノードと通信する手段として TLS セキュリティネゴシエーションの仕組みを要求する。
5) ATNA はローカルなユーザ認証のみを要求する。EUA も選択の一つだが、これを使う必要は無い。
6) 携帯機器に関する特別な面には言及しない。
接続認証(Node Authentication)については、次の要件が記載されている。
1) 各ノードの接続に対して、双方向の証明書ベースのノード認証を要求する。
2) DICOM,HL7,HTML の各プロトコルは全て証明書ベースの決まった認証機構を持っている。ユーザではなく、ノードを認証している。
3) 双方向のノード認証ができない機器の接続は禁止されるか、PHI アクセスを防ぐようにする。
監査証跡(Audit Trail)については、次の要件が記載されている。
1) 監査は常に選択したアクセス制御と認証方法とは独立していなければならない。
2) 記録は単に個々の IHE アクタに相当する個々のコンポーネントだけではなく、全体のプロセスに対するイベントの記述を捕まえなければならない。
3) 監査記録メッセージは、集中監査リポジトリへログ採取が行われる。仕組みは、
Reliable Syslog Cooked Profile(RFC-3195) に 使 い 方 を 規 定 し て い る 。 BSD
Syslog(RFC-3164)も使用可能だが制約がある。
①参照する標準規格
ATNA ではトランザクションにより異なる標準規格を参照している。
１）トランザクション「時間保守機能」
NTP Network Time Protocol Version 3. RFC1305

62

地域医療連携情報システム構築ハンドブック 201１ 附属書SNTP Simple Network Time Protocol (SNTP) RFC2030
２）トランザクション「ノード認証」
DICOM 2003 PS 3.15:Security Profiles. Annex B1:The Basic TLS Secure Transport
Connection profile
IETF: Transport Layer Security (TLS) 1.0 (RFC 2246)
ITU-T: Recommendation X.509 (03/00).“Information technology - Open Systems
Interconnection – The directory: Public-key and attribute certificate frameworks"
３）トランザクション「監査イベント記録」
IETF: The BSD Syslog Protocol. (RFC 3164);Reliable Delivery for Syslog (RFC3195);Security Audit and Access Accountability Message XML Data Definitions for
Healthcare Applications (RFC 3881).
DICOM Supplement 95，c)ASTM: E2147-01 Standard Specification for Audit andDisclosure Logs for Use in Health Information Systems.
W3C: Recommendation: Extensible Markup Language (XML) 1.0②監査イベント記録
ATNA では取得するべき監査イベント記録が規定されている。DICOM 等で定義されているものの他に IHE 独自に定義しているイベントが多数ある。また、イベントは CP 等で都度追加／訂正されているのが実情である。
（２）利用方法
ATNA 統合プロファイルは、ノード認証・監査証跡（時間保守含む）共に導入についての技術的な問題点は存在しないと考える。今後、益々ログ情報等の取得が医療情報シ
ステムの運用時の重要な要件となることは間違いないので導入を進めるべき分野だといえる。
ATNA 統合プロファイルを医療機関内で利用する場合は、許可されないシステムや機器が導入されている可能性が低いので NA(Node Authentication)は導入の必要性は低いと考える。地域医療連携システムについてもどのようなネットワーク環境を利用して施設同士を接続するかにより、NA の導入要否を検討すればよいだろう。
AT(Audit Trail)機能については、施設内のシステムや利用状況の監査よりもより厳密に監査し導入すべきである。但し、監査証跡で取得すべきイベントについては、その要否及び過不足について十分な検討が必要である。

63

地域医療連携情報システム構築ハンドブック 201１ 附属書D.2.2 CT（１）統合プロファイル概要
CT は、対象となるシステムを構成する各装置の内部時計の時刻を合わせる機能を提供する。これにより、データの生成時刻などの整合性を保つとともに、取り扱う情報のセ
キュリティを担保するための監査証跡の有効性を高めることができる。本プロファイルでは、基準となる時計を持つ Time Server との通信により、各装置の内部時計を合わせる
トランザクションが規定されている。
（２）利用方法
CT 統合プロファイルによる時刻同期は、正確な監査証跡の取得や障害発生時の切り分け情報のために大切な機能である。利用には、まず施設内にタイムサーバを導入することが必須である。現在では、電波で正確な時刻を取得してタイムサーバ機能を実現する機器も販売されているので活用いただきたい。さらに、クライアント PC の OS に標準に実現されている時刻合わせ機能での設定でよいので、時刻同期を行いシステム内のサーバ・クライアントがすべて同じ時刻となるように運用することを推奨する。
D.3

監査証跡の要求仕様書記載のポイント（ポイント１）
実現するシステムの各機能で、
a)ノード認証、
b)監査証跡ログの出力、
c)時刻同期の実施を行う旨を記載する。
特に、いつどのようなタイミングで認証、ログ出力を実施するか、また、時刻同期を行う
頻度などは明確にする必要がある。特に監査証跡ログを出力するイベントは十分検討する必要がある。
（ポイント２）
ノード認証、監査証跡ログ機能、時刻同期の基本的な手順及び技術的なメカニズムについては別途まとめるとよい。
D.3.1 監査証跡ログを記載するイベントの抽出方法
監査証跡ログを記載すべきイベントについては、テクニカルフレームワークに記載されている情報を参考に、各システムで検討する必要がある。また、IT インフラストラクチャのテクニカルフレームワークには、統合プロファイルごとに出力する監査証跡ログの記載がある。こちらもあわせて確認する必要がある。
ITI の テ ク ニ カ フ レ ー ム ワ ー ク が 参 照 し て い る ロ グ イ ベ ン ト は 、 DICOM 規 格 の64地域医療連携情報システム構築ハンドブック 201１ 附属書Supplement95”Audit Trail Messages”である。あわせて確認願いたい。
表 D-1 監査証跡ログ出力のトリガーイベント一覧
トリガーイベント
Actor-start-stop
Audit-Log-Used
Begin-storing-instances

Health-service-event

Instances-deleted

Instances-Stored

Medication

Mobile-machine-event

Node-Authenticationfailure
Order-record-event

Patient-care-assignment

Patient-care-episode

Patient-care-protocol

Patient-record-event
PHI-export

説明
ソース用語
あらゆるアクタの起動および停止。全てのアクタに適用 DICOM (Sup 95) “アする。ハードウエアの電源入力や運転停止とは区別する。 プリケーション活動”
監査証跡リポジトリは、監査証跡メッセージの到着以外 DICOM (Sup 95) “使によってアクセスまたは修正される。
用した監査ログ”検査のためにSOPインスタンスを保存開始する。これは DICOM (Sup 95)
インスタンスの混ざったものである。
“DICOMインスタン
スを搬送し始める”
ケアのインスタンスやエピソード内で計画し実行するヘ IHE 拡 張 (ITI TF-2a:
ルスサービス。この中にはスケジューリング、開始、更 3.20.7.3) “ヘルスサ
新または修正、行動の実行または完了、およびキャンセ ービス提供イベント”
ルを含んでいる。下記注を参照。
SOPインスタンスを特定の検査から削除する。1つのイベ DICOM (Sup 95)
ントは特別の検査のために削除した全てのインスタンス “DICOMインスタンを対象とする。
ス ア ド レ ス ”ま た は“DICOM検査削除”
特別の検査のためのインスタンスはこのシステムに保存 DICOM (Sup 95)
される。1つのイベントは特別の検査のために保存した全 “DICOMインスタンてのインスタンスを対象とする。
ス転送”
ケアのインスタンスまたはエピソード内での投薬オーダ IHE 拡 張 (ITI TF-2a:および投与。この中には初期オーダ、調剤、搬送および 3.20.7.3)“薬剤イベン
キャンセルを含んでいる。下記注を参照。
ト”
移動型機器が安全ドメインに加わるか離れる。
DICOM (Sup 95)“ネッ ト ワ ー ク エン ト リー”
安全ノード認証の不成功はTLSネゴシエーションのとき DICOM (Sup 95)“セに発生する、例えば、無効な証明書。
キュリティ警告“
作成、アクセス、修正または削除したオーダ記録。関連 DICOM (Sup 95)“オするアクタ：オーダ発行。この中には初期オーダ、更新 ーダ記録”
または修正、搬送、完了、およびキャンセルを含む。下記注を参照。
医療専門家、担当医、レジデント、医学生、コンサルタ IHE 拡 張 (ITI TF-2a:ント等に関するスタッフまたは関与者の患者に対する任 3.20.7.3)“患者ケアリ
務割当て行動。これは、与えられた役割または権限の変 ソース割当”
更、例えば、医療行為ステータスの変更や任務変更、をも含んでいる。
ケアのインスタンス内で発生する特定の患者ケアエピソ IHE 拡 張 (ITI TF-2a:ードまたは問題。この中には最初の任務、更新または修 3.20.7.3)“患者ケアエ
正、意思決定、完了、およびキャンセルを含んでいる。 ピソード”
下記注を参照。
ケアプロトコルとの患者アソシエーション。これは最初 IHE 拡 張 (ITI TF-2a:の任務、スケジューリング、更新または修正、完了、お 3.20.7.3)“患者ケアプ
よびキャンセルを含む。下記注を参照。
ロトコル”
作成、修正またはアクセスした患者記録。
DICOM (Sup 95)“患者記録”
CD-ROM可などの可搬型物理的メディアまたは電子メー DICOM (Sup 95)“書ルなどのファイルの電子トランスファーのようなメディ き出し”
ア上でのPHIの全ての書き出し。紙、フィルム、ローカル
または遠隔のPHIを印刷する全ての印刷行為。

65

地域医療連携情報システム構築ハンドブック 201１ 附属書

PHI-import

Procedure-record-event
Query Information

Security Alert

User Authentication

Study-Object-Event

CD-ROM可などの可搬型物理的メディアまたは電子メー
ルなどのファイルの電子トランスファーのようなメディ
ア上でのPHIの全ての読み込み。
作成、修正またはアクセスした医療行為記録。

DICOM (Sup 95)“読み込み”
DICOM (Sup 95)“検査手続き記録”DICOM (Sup 95)“問い合わせ”IHEトランザクションの一部またはその他の製品の機能の一部として問合せを受け取っている。例えば、1）モダ
リティワークリスト問い合わせ、2）インスタンスまたは利用可能画像問い合わせ、3）PIX、PDQ、またはXDS問
い合わせ。注：一般的ガイダンスは問い合わせパラメー
タとともに問い合わせイベントをログすることであり、問い合わせの結果ではない。問い合わせの結果は非常に大きくオーバーヘッドに対して制限された値となる可能性がある。問い合わせパラメータは間違った動作を検出するために有効であり、問い合わせパラメータが分かると結果も分かることが期待される。
セキュリティ管理動作は、以下の作成、修正、削除、問 DICOM (Sup 95) “セい合わせおよび表示を行う：
キュリティ警告”
1.構成やその他の変更、例えば、防護された情報を処理する全てのソフトウエアに影響を与えるソフトウエア更新。ハードウエアの変更もこのイベントで報告してもよい。
2.患者管理、臨床処理、ビジネスオブジェクトと方法の登録（例えば、WSDL、UDDI)、プログラム作成とメンテ
ナンス、等々に用いるアプリケーション機能に対するセキュリティ属性および監査可能なイベント
3.例えば、実在する全ての、組織化、部門化された等の種々の団体組織に従ったセキュリティドメイン。
4.例えば、患者管理、看護、臨床等々の機能とデータのためのセキュリティ分類区分またはグループ。
5.機能およびデータと関連する許可されたアクセス、例
えば、特定の機能ユニットまたはオブジェクトアクセス
または操作方法の作成、読取り、更新、削除および実行。
6.種々のタスクグルーピング分類に従ったセキュリティの役割、例えば、セキュリティ管理、入院デスク、看護師、医師、臨床専門家、等々。役割ベースのアクセス管理の役割と許可の関係をも含んでいる。
7.ユーザアカウント。これはパスワードまたはその他の認証データの割当てまたは変更を含む。ユーザベースのアクセス管理のユーザとの役割関係、またはユーザベー
スのアクセス管理のユーザとの許可関係をも含んでいる。
8.許可されていないユーザがセキュリティ管理機能を使おうとする。
9.監査の権限付与および権限無効化
10.ユーザ認証のキャンセル
11.緊急モードアクセス(即ち、Break-Glass)
セキュリティ管理イベントは常に監査されることが望ましい。
このメッセージは、成功不成功に関係なくログオンまた DICOM (Sup 95) “ユはログオフしようとするユーザのイベントについて述べ ーザ認証”ている。このメッセージに参加者オブジェクトを必要としない。
検査は作成、修正、アクセスまたは削除される。既存の DICOM (Sup 95)

66

地域医療連携情報システム構築ハンドブック 201１ 附属書

Study-used

検査への新しいインスタンスの追加および新しい検査の作成について、これは報告している。
特定の検査からのSOPインスタンスが作成、修正またはアクセスされる。1つのイベントが特別の検査に用いる全てのインスタンスを対象としている。

“DICOMインスタン
スアクセス”DICOM (Sup 95)“ DICOM イ ン ス タ
ンスアクセス”

注： IHE拡張機能は、“臨床上の禁忌をチェック”というような語句を削除するために多くのIETFイベン
トの適用範囲を狭めた。これは、報告すべきイベントはPHIのアクセス、使用、作成、および配布に関連するものを強調するために行う。この監査ログは全ての医療活動を追跡するための汎用目的の監視システムを目的としてはいない。その結果、多くの臨床上の有意なイベントは独立して報告していない。

表 D-2 監査証跡ログ出力イベントのコード値一覧
コード値
IHE0001

コードの意味ヘルスサービス提供イ
ベント

IHE0002

投薬イベント

IHE0003

患者ケアリソース割当てIHE0004

患者ケアエピソード

IHE0005

患者ケアプロトコル

定義
ケアのインスタンス又はエピソード内で予約され実行されるヘルスサービス。これはスケジューリング、開始、更新または修正、行動の実行または完了、およびキャンセルを含んでいる。
ケアのインスタンス又はエピソード内での投薬治療指示および投与。
これは最初の指示、調剤、配送、およびキャンセルを含む。
医療専門家、担当医、レジデント、医学生、コンサルタント等に関するスタッフまたは関与者の患者に対する任務割当て行動。これは、与えられた役割または権限の変更、例えば、医療行為ステータスの変更
や任務変更、をも含んでいる。
ケアのインスタンス内で発生する特定の患者ケアエピソードまたは問題。この中には最初の任務、更新または修正、意思決定、完了、およびキャンセルを含んでいる。
ケアプロトコルとの患者アソシエーション。これは最初の任務、スケ
ジューリング、更新または修正、完了、およびキャンセルを含む。

補足：表 D-1 は、DICOM 規格から抜粋したトリガーイベントである。表 D-2 は、IHE が独自に検討して定義した監査証跡ログ出力イベントのコード値である。
D.3.2 監査証跡ログイベントの例
トリガーイベントを参考に監査証跡ログを出力すべきイベントをいくつか挙げる。実際には、実現するシステムに適したイベントを検討する必要があるので留意されたい。
＜イベント例＞
1) システムの起動／終了
2) ログサーバの起動／終了
3) ユーザ認証実行
4) ユーザ認証失敗（セキュリティアラート）
5) 文書／画像データ登録
6) 文書／画像データ検索
7) 文書／画像データ参照
8) 文書／画像データ抽出 export9) 患者データの検索67

地域医療連携情報システム構築ハンドブック 201１ 附属書

D.3.3 監査証跡ログに記載すべきこと
監査メッセージの書式として RFC3881 で定義されたものを使用する。
監査メッセージには、「誰が」、「いつ」、「どのサーバ／端末から」、「どのサーバ／端末
へ」、「どのデータに対して」「どうしたか」が記述される。本資料作成時には RFC2881 に定義されている監査証跡ログのスキーマ（メッセージ構造）はリタイアされていて取得することができない。附属書 D.5.3 に当該スキーマを掲載する。
監査ログ関連の仕様書記載例

D.4

文書情報登録機能について、１）監査証跡ログ出力、2)時刻同期を実現するための記載例を以下に示す。
文書情報登録機能は、以下の要件を満たすこと。
① 作成された pdf 形式のデータファイルを地域連携サーバに登録する機能を有すること。
② 地域連携サーバに登録時には登録した旨を示す監査証跡ログを出力すること。監査証

跡ログの出力は、IHE-IT インフラストラクチャ領域の ATNA(Audit Trail and Node
Authentication)統合プロファイルの Audit Trail-Secure Node アクタを利用すること。
③ 監査証跡ログのイベント ID 等ログ内容の詳細は別途指定したとおりとすること。
④ 正確な情報収集のために、時刻サーバを導入する予定である。文書登録機能は、指定した時刻サーバと時刻同期を行うこと。時刻同期には、IHE-IT インフラストラクチャのCT(Consistent Time)統合プロファイルの Time Client アクタを利用すること。時刻同期は１回／日で実施することとする。実施時間は別途調整する。

D.5 監査証跡ログの例
ここでは、具体的な監査証跡ログの形式について提示する。
D.5.1

監査証跡ログのユースケース① 患者 A は、心臓が悪い。
② 自宅で、息切れと疲労感を自覚し、地域連携システムの機能を利用し、自分の医療情報を外部に持ち出す準備を行う。
③ かかりつけ医は、EMR へ患者 A の医療情報を取り込む。診察の結果、循環器科への受診を決め、紹介状を作成し、地域連携システムへ登録する。
④ 循環器医は、かかりつけ医からの紹介状を見て個人記録へ追加する。患者 A は診察
時に胸部痛を訴えたため、救急外来に紹介する。

68

地域医療連携情報システム構築ハンドブック 201１ 附属書⑤ 患者 A の隣に住んでいる医師 BB は同じ循環器科で働いており、患者 A が受診したことに気づく。医師 BB は、自身の ID で患者 A の記録を入手しようとするが責任者でないため、不可となる。
⑥ 救急外来では、循環器医からの紹介状を参照する。救急外来医は特権を必要としないので、患者 A の記録を参照することが可能である。
⑦ プライバシ部門責任者は、患者 A の監査証跡ログから異常な事象の警告を得る。報告内容は、医師 BB の不正な医療情報入手の企てや、救急外来医による救急目的の医療情報参照を表示する。この報告は、開示用ログの作成にも役立つ。

D.5.2

監査証跡ログの出力形式（１）文書データ取得時に、文書データを取得する側（Consumer）が出力

Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110107, DCM, "Import")

EventActionCode

M"C" (Create)

EventDataTime

M

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV("ITI-17", "IHE
"Retrieve Document")

Transactions",

Source (Document Repository) (1)Destination (Document Consumer) (1)
Human Requestor (0..n)
Audit Source (1)Patient (0..1)
Document URI (1)Where:

SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParitcipant

Field Name
UserID
AlternativeUserID
UserName
UserIsRequestor
RoleIDCode

Opt
U
U
U
M
M

NetworkAccessPointTypeCode

M

NetworkAccessPointID

M

Field Name
UserID

Opt
U

AlternativeUserID

M

UserName
UserIsRequestor
RoleIDCode

U
M
M

69

Value Constraints
not specialized
not specialized
not specialized"false"EV(110153, DCM, "Source")"1" for machine (DNS) name, "2" for IP
adressThe machine name or IP adress, as
specified in RFC 3881.
Value Constraints
not specialized
the process ID as used within the local
operating system in the local system logs.
not specialized"true"
EV(110152, DCM, "Destination")

地域医療連携情報システム構築ハンドブック 201１ 附属書

HumanRequestor(if known)
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSource
Identification

Patient(if known)
AuditMessage/
ParticipantObjectIde
ntification

Document URI
AuditMessage/
ParticipantObjectIde
ntification"1" for machine (DNS) name, "2" for IP
adressThe machine name or IP adress, as
specified in RFC 3881.
Value Constraints
Identity of the human that initiated thetransaction.
not specialized
not specialized"true"
Access Control role(s) the user holds thatallows this transaction.

NetworkAccessPointTypeCode

M

NetworkAccessPointID

M

Field Name

Opt

U serID

M

AlternativeUserID
UserName
UserIsRequestor

U
U
M

RoleIDCodeU

NetworkAccessPointTypeCode
NetworkAccessPointID
Field Name
AuditSourceID
AuditEnterpriseSiteID
AuditSourceTypeCode
Field Name
ParticipantObjectTypeCode
ParticipantObjectTypeCodeRole
ParticipantObjectDataLifeCycle

NA
NA
Opt
U
U
U
Opt
M
M
U

Value Constraints
not specialized
not specialized
not specialized
Value Constraints"1" (Person)"1" (Patient)
not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, "Patient Number")ParticipantObjectSensitivity
ParticipantObjectID
ParticipantObjectName
ParticipantObjectQuery
ParticipantObjectDetail

U
M
U
U
U

not specialized
The patient ID in HL7 CX format.
not specialized
not specialized
not specialized

Field Name

Opt

Value Constraints

ParticipantObjectTypeCode
ParticipantObjectTypeCodeRole
ParticipantObjectDataLifeCycle
ParticipantObjectIDTypeCode
ParticipantObjectSensitivity
ParticipantObjectID

M
M
U
M
U
M

"2" (system)"3" (report)
not specialized
EV(12, RFC-3881, "URI")
not specialized
Document URI

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

ParticipantObjectDetailMCnot specialized
Type=XDSDocumentEntry.uniqueId (theliteral string), Value=the value of theDocument Unique ID (from the XDS
metadata)（２）文書データ取得時に、文書データを提供する側（Repository）が出力
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110107, DCM, "Export")

EventActionCode

M"C" (Create)

EventDataTime

M

not specialized

EventOutcomeIndicatorM

not specialized70

地域医療連携情報システム構築ハンドブック 201１ 附属書

M

EV("ITI-17", "IHE Transactions","Retrieve Document")

Field Name

Opt

Value Constraints

UserIDU

not specialized

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM"false"RoleIDCodeM

EV(110153, DCM, "Source")

NetworkAccessPointTypeCode

M

NetworkAccessPointID

M

Field Name

Opt

Value Constraints

UserIDU

not specialized

AlternativeUserIDM

the process ID as used within the local
operating system in the local system
logs.

UserNameUnot specialized

UserIsRequestorM"true"

RoleIDCodeM

EV(110152, DCM, "Destination")

NetworkAccessPointTypeCode

M

NetworkAccessPointID

M

Field Name

Opt

Value Constraints

UserID

M

Identity of the human that initiated thetransaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM"true"

RoleIDCodeU

Access Control role(s) the user holds
that allows this transaction.

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

Audit Source
AuditMessage/
AuditSource
Identification

Field Name

Opt

Value Constraints

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

Patient(if known)

Field Name

Opt

Value Constraints

ParticipantObjectTypeCodeM"1" (Person)

EventTypeCode
Source (Document Repository) (1)Destination (Document Consumer) (1)
Human Requestor (0..n)
Audit Source (1)Patient (0..1)
Document URI (1)Where:

SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Human
Requestor(if known)
AuditMessage/
ActiveParticipant

71"1" for machine (DNS) name, "2" forIP adress
The machine name or IP adress, as
specified in RFC 3881.

"1" for machine (DNS) name, "2" forIP adress
The machine name or IP adress, as
specified in RFC 3881.

地域医療連携情報システム構築ハンドブック 201１ 附属書

AuditMessage/
ParticipantObjectIdentification

Document URI
AuditMessage/
ParticipantObjectIdentificationParticipantObjectTypeCodeRoleM"1" (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, "Patient Number")ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

Field Name

Opt

Value Constraints

ParticipantObjectTypeCodeM"2" (system)

ParticipantObjectTypeCodeRoleM"3" (report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(12, RFC-3881, "URI")

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

Document URI

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

MC

Type=XDSDocumentEntry.uniqueId(the literal string), Value=the value of
the Document Unique ID (from the
XDS metadata)

ParticipantObjectDetail（３）文書データ登録時に、文書を登録する側（Source）が出力

Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110106, DCM, "Export")

EventActionCode

M"R" (Read)

EventDataTime

M

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV("ITI-14", "IHE Transactions","Register Document Set")

Source (Document Repository or Integrated Document Source/Repository) (1)
Human Requestor (0..n)
Destination (Document Registory) (1)Audit Source (Document Repository or Integrated Document Source/Repository) (1)Patient (1)SubmissionSet (1)Where:

SourceAuditMessage/
ActiveParticipant

Field Name

Opt

Value Constraints

UserIDU

not specialized

AlternativeUserIDM

the process ID as used within the local
operating system in the local system
logs.

UserNameUnot specialized

UserIsRequestorM"true"

RoleIDCodeM

EV(110153, DCM, "Source")

NetworkAccessPointTypeCodeM"1" for machine (DNS) name, "2" for72

地域医療連携情報システム構築ハンドブック 201１ 附属書IP adress

Human
Requestor(if known)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSource
Identification

Patient
AuditMessage/
ParticipantObject
Identification

SubmissionSet
AuditMessage/
ParticipantObject
Identification

NetworkAccessPointID

M

The machine name or IP adress, as
specified in RFC 3881.

Field Name

Opt

Value Constraints

UserID

M

Identity of the human that initiated thetransaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM"true"

RoleIDCodeU

Access Control role(s) the user holds
that allows this transaction.

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

Field Name

Opt

Value Constraints

UserID

M

SOAP endpoint URI.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM"false"RoleIDCodeM

EV(110152, DCM, "Destination")

NetworkAccessPointTypeCode

M

NetworkAccessPointID

M

Field Name

Opt

Value Constraints

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

Field Name

Opt

Value Constraints

ParticipantObjectTypeCodeM"1" (person)

ParticipantObjectTypeCodeRoleM"1" (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, "Patient Number")ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format..

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

Field Name

Opt

Value Constraints

ParticipantObjectTypeCodeM"2" (System)

ParticipantObjectTypeCodeRole

M"20" (job)ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV("urn:uuid:a54d6aa5-d40d-43f9-8
8c5-b4633d873bdd","IHE
XDS
Metadata","submission
setclassificationNode")

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the submissionSet unique ID

73"1" for machine (DNS) name, "2" forIP adress
The machine name or IP adress, as
specified in RFC 3881.

地域医療連携情報システム構築ハンドブック 201１ 附属書

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized（４）文書データ登録時に、文書データを登録される側（Repository）が出力

Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110107, DCM, “Import”)

EventActionCode

M"C" (Create)

EventDataTime

M

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV("ITI-14", "IHE Transactions","Register Document Set")

Source (Document Repository or Integrated Document Source/Repository) (1)Destination (Document Registory) (1)Audit Source (Document Registory) (1)Patient (1)SubmissionSet (1)Where:
Field Name

Opt

Value Constraints

UserIDU

not specialized

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM"true"

RoleIDCodeM

EV(110153, DCM, "Source")

NetworkAccessPointTypeCode

M

NetworkAccessPointID

M

Field Name

Opt

Value Constraints

UserIDU

SOAP endpoint URI

AlternativeUserIDM

the process ID as used within the local
operating system in the local system
logs.

UserNameUnot specialized

UserIsRequestorM"false"RoleIDCodeM

EV(110152, DCM, "Destination")

NetworkAccessPointTypeCode

M

NetworkAccessPointID

M

Audit Source
AuditMessage/
AuditSource
Identification

Field Name

Opt

Value Constraints

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

Patient
AuditMessage/

Field Name

Opt

Value Constraints

ParticipantObjectTypeCodeM"1" (person)

SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

74"1" for machine (DNS) name, "2" for IP
adressThe machine name or IP adress, as
specified in RFC 3881.

"1" for machine (DNS) name, "2" for IP
adressThe machine name or IP adress, as
specified in RFC 3881.

地域医療連携情報システム構築ハンドブック 201１ 附属書

ParticipantObject
Identification

SubmissionSet
AuditMessage/
ParticipantObject
Identification

D.5.3

ParticipantObjectTypeCodeRoleM"1" (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, "Patient Number")ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format..

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

Field Name

Opt

Value Constraints

ParticipantObjectTypeCodeM"2" (System)

ParticipantObjectTypeCodeRole

M"20" (job)ParticipantObjectDataLifeCycle

U

not specializedM

EV("urn:uuid:a54d6aa5-d40d-43f9-88c
5-b4633d873bdd","IHE
XDS
Metadata","submission
setclassificationNode")

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the submissionSet unique ID

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectIDTypeCode

監査証跡ログのスキーマ<!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by Glen F. Marshall(HL7 Technical Steering Committee) --><xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">- <xs:element name="AuditMessage">- <xs:complexType>- <xs:sequence><xs:element name="EventIdentification" type="EventIdentificationType" />- <xs:element name="ActiveParticipant" maxOccurs="unbounded">- <xs:complexType>- <xs:complexContent><xs:extension base="ActiveParticipantType" /></xs:complexContent></xs:complexType></xs:element><xs:element
name="AuditSourceIdentification"
type="AuditSourceIdentificationType"
maxOccurs="unbounded" /><xs:element
name="ParticipantObjectIdentification"
type="ParticipantObjectIdentificationType" minOccurs="0" maxOccurs="unbounded" /></xs:sequence>75

地域医療連携情報システム構築ハンドブック 201１ 附属書</xs:complexType></xs:element>- <xs:complexType name="EventIdentificationType">- <xs:sequence><xs:element name="EventID" type="CodedValueType" /><xs:element name="EventTypeCode" type="CodedValueType" minOccurs="0"
maxOccurs="unbounded" /></xs:sequence>- <xs:attribute name="EventActionCode" use="optional">- <xs:simpleType>- <xs:restriction base="xs:string">- <xs:enumeration value="C">- <xs:annotation><xs:appinfo>Create</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="R">- <xs:annotation><xs:appinfo>Read</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="U">- <xs:annotation><xs:appinfo>Update</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="D">- <xs:annotation><xs:appinfo>Delete</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="E">- <xs:annotation><xs:documentation>Execute</xs:documentation></xs:annotation></xs:enumeration></xs:restriction></xs:simpleType></xs:attribute><xs:attribute name="EventDateTime" type="xs:dateTime" use="required" />- <xs:attribute name="EventOutcomeIndicator" use="required">- <xs:simpleType>- <xs:restriction base="xs:integer">- <xs:enumeration value="0">- <xs:annotation><xs:appinfo>Success</xs:appinfo>76

地域医療連携情報システム構築ハンドブック 201１ 附属書</xs:annotation></xs:enumeration>- <xs:enumeration value="4">- <xs:annotation><xs:appinfo>Minor failure</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="8">- <xs:annotation><xs:appinfo>Serious failure</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="12">- <xs:annotation><xs:appinfo>Major failure; action made unavailable</xs:appinfo></xs:annotation></xs:enumeration></xs:restriction></xs:simpleType></xs:attribute></xs:complexType>- <xs:complexType name="AuditSourceIdentificationType">- <xs:sequence><xs:element name="AuditSourceTypeCode" type="CodedValueType"minOccurs="0" maxOccurs="unbounded" /></xs:sequence><xs:attribute name="AuditEnterpriseSiteID" type="xs:string" use="optional" /><xs:attribute name="AuditSourceID" type="xs:string" use="required" /></xs:complexType>- <xs:complexType name="ActiveParticipantType">- <xs:sequence minOccurs="0"><xs:element name="RoleIDCode" type="CodedValueType" minOccurs="0"
maxOccurs="unbounded" /></xs:sequence><xs:attribute name="UserID" type="xs:string" use="required" /><xs:attribute name="AlternativeUserID" type="xs:string" use="optional" /><xs:attribute name="UserName" type="xs:string" use="optional" /><xs:attribute name="UserIsRequestor" type="xs:boolean" use="optional"
default="true" /><xs:attribute name="NetworkAccessPointID" type="xs:string" use="optional" />- <xs:attribute name="NetworkAccessPointTypeCode" use="optional">- <xs:simpleType>- <xs:restriction base="xs:unsignedByte">- <xs:enumeration value="1">- <xs:annotation><xs:appinfo>Machine Name, including DNS name</xs:appinfo>77

地域医療連携情報システム構築ハンドブック 201１ 附属書</xs:annotation></xs:enumeration>- <xs:enumeration value="2">- <xs:annotation><xs:appinfo>IP Address</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="3">- <xs:annotation><xs:appinfo>Telephone Number</xs:appinfo></xs:annotation></xs:enumeration></xs:restriction></xs:simpleType></xs:attribute></xs:complexType>- <xs:complexType name="ParticipantObjectIdentificationType">- <xs:sequence><xs:element name="ParticipantObjectIDTypeCode" type="CodedValueType" />- <xs:choice minOccurs="0"><xs:element name="ParticipantObjectName" type="xs:string" minOccurs="0" /><xs:element
name="ParticipantObjectQuery"
type="xs:base64Binary"
minOccurs="0" /></xs:choice><xs:element
name="ParticipantObjectDetail"type="TypeValuePairType"minOccurs="0" maxOccurs="unbounded" /></xs:sequence><xs:attribute name="ParticipantObjectID" type="xs:string" use="required" />- <xs:attribute name="ParticipantObjectTypeCode" use="optional">- <xs:simpleType>- <xs:restriction base="xs:unsignedByte">- <xs:enumeration value="1">- <xs:annotation><xs:appinfo>Person</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="2">- <xs:annotation><xs:appinfo>System object</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="3">- <xs:annotation><xs:appinfo>Organization</xs:appinfo></xs:annotation></xs:enumeration>78

地域医療連携情報システム構築ハンドブック 201１ 附属書- <xs:enumeration value="4">- <xs:annotation><xs:appinfo>Other</xs:appinfo></xs:annotation></xs:enumeration></xs:restriction></xs:simpleType></xs:attribute>- <xs:attribute name="ParticipantObjectTypeCodeRole" use="optional">- <xs:simpleType>- <xs:restriction base="xs:unsignedByte">- <xs:enumeration value="1">- <xs:annotation><xs:appinfo>Patient</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="2">- <xs:annotation><xs:appinfo>Location</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="3">- <xs:annotation><xs:appinfo>Report</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="4">- <xs:annotation><xs:appinfo>Resource</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="5">- <xs:annotation><xs:appinfo>Master file</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="6">- <xs:annotation><xs:appinfo>User</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="7">- <xs:annotation><xs:appinfo>List</xs:appinfo></xs:annotation></xs:enumeration>79

地域医療連携情報システム構築ハンドブック 201１ 附属書- <xs:enumeration value="8">- <xs:annotation><xs:appinfo>Doctor</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="9">- <xs:annotation><xs:appinfo>Subscriber</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="10">- <xs:annotation><xs:appinfo>Guarantor</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="11">- <xs:annotation><xs:appinfo>Security User Entity</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="12">- <xs:annotation><xs:appinfo>Security User Group</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="13">- <xs:annotation><xs:appinfo>Security Resource</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="14">- <xs:annotation><xs:appinfo>Security Granualarity Definition</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="15">- <xs:annotation><xs:appinfo>Provider</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="16">- <xs:annotation><xs:appinfo>Report Destination</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="17">80

地域医療連携情報システム構築ハンドブック 201１ 附属書- <xs:annotation><xs:appinfo>Report Library</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="18">- <xs:annotation><xs:appinfo>Schedule</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="19">- <xs:annotation><xs:appinfo>Customer</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="20">- <xs:annotation><xs:appinfo>Job</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="21">- <xs:annotation><xs:appinfo>Job Stream</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="22">- <xs:annotation><xs:appinfo>Table</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="23">- <xs:annotation><xs:appinfo>Routing Criteria</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="24">- <xs:annotation><xs:appinfo>Query</xs:appinfo></xs:annotation></xs:enumeration></xs:restriction></xs:simpleType></xs:attribute>- <xs:attribute name="ParticipantObjectDataLifeCycle" use="optional">- <xs:simpleType>- <xs:restriction base="xs:unsignedByte">- <xs:enumeration value="1">81地域医療連携情報システム構築ハンドブック 201１ 附属書- <xs:annotation><xs:appinfo>Origination / Creation</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="2">- <xs:annotation><xs:appinfo>Import / Copy from original</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="3">- <xs:annotation><xs:appinfo>Amendment</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="4">- <xs:annotation><xs:appinfo>Verification</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="5">- <xs:annotation><xs:appinfo>Translation</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="6">- <xs:annotation><xs:appinfo>Access / Use</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="7">- <xs:annotation><xs:appinfo>De-identification</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="8">- <xs:annotation><xs:appinfo>Aggregation, summarization, derivation</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="9">- <xs:annotation><xs:appinfo>Report</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="10">- <xs:annotation>82

地域医療連携情報システム構築ハンドブック 201１ 附属書<xs:appinfo>Export / Copy to target</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="11">- <xs:annotation><xs:appinfo>Disclosure</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="12">- <xs:annotation><xs:appinfo>Receipt of disclosure</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="13">- <xs:annotation><xs:appinfo>Archiving</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="14">- <xs:annotation><xs:appinfo>Logical deletion</xs:appinfo></xs:annotation></xs:enumeration>- <xs:enumeration value="15">- <xs:annotation><xs:appinfo>Permanent erasure / Physical destruction</xs:appinfo></xs:annotation></xs:enumeration></xs:restriction></xs:simpleType></xs:attribute><xs:attribute name="ParticipantObjectSensitivity" type="xs:string" use="optional" /></xs:complexType>- <xs:complexType name="CodedValueType"><xs:attribute name="code" type="xs:string" use="required" /><xs:attributeGroup ref="CodeSystem" /><xs:attribute name="displayName" type="xs:string" use="optional" /><xs:attribute name="originalText" type="xs:string" use="optional" /></xs:complexType>- <xs:complexType name="TypeValuePairType"><xs:attribute name="type" type="xs:string" use="required" /><xs:attribute name="value" type="xs:base64Binary" use="required" /></xs:complexType>- <xs:attributeGroup name="CodeSystem"><xs:attribute name="codeSystem" type="OID" use="optional" /><xs:attribute name="codeSystemName" type="xs:string" use="optional" />83

地域医療連携情報システム構築ハンドブック 201１ 附属書</xs:attributeGroup>- <xs:simpleType name="OID">- <xs:restriction base="xs:string"><xs:whiteSpace value="collapse" /></xs:restriction></xs:simpleType></xs:schema>84Proxy地域医療連携情報システム構築ハンドブック
Reposi tory 201１ 附属書

附属書 E. XCA 概説
本プロファイルは、コミュニティ（共通のポリシに合意した医療機関の集合、XDS アフィ
ニティドメイン(XAD)とも呼ばれる）間で患者診療情報（ドキュメント）を共有するための手段を提供するものである。トランザクションは XDS.b 統合プロファイルのものを前提としている。コミュニティは homeCommunityId でグローバルに特定される。医療機関がどのコミュニティに属するかについて制限はない。またコミュニティとしては必ずしも XDSの構成があることは想定していない。
Document Consumer に対するサービスは、コミュニティ内でのドキュメント問い合わせの場合と同じ仕様となっており、コミュニティの内も外も一貫したトランザクションを使うこと
Initiating GW
Responding GWができる。どのコミュニティが情報を伝え合うかを確認する方法、あるいは情報を伝え合
うときに用いる患者 ID の確認方法については(PIX、PDQ などを基本として使う方法はあるが)、本プロファイルのスコープ外である。
本プロファイルは、IHE IT Infrastructure Technical Framework Cross-Community
Access XCA （Trial Implementation Supplement August 10, 2010）として改訂発行されたが 2011 年８月１９日に ITI Rev.8.0 テクニカルフレームワークに収載されたものである。
E.1 アクタとトランザクション
図 E-1 にアクタとトランザクションを示す。問い合わせのアクションを起こすコミュニティ
側が開始コミュニティ（Initiating Community）であり、問い合わせに答えるコミュニティ側が応答コミュニティ（Responding Community）である。

図 E-1 XCA アクタとトランザクション

85

地域医療連携情報システム構築ハンドブック 201１ 附属書E.1.1 XCA アクタ
以下、アクタの解説を行う。
E.1.1.1 ドキュメント利用者（Document Consumer）
ドキュメントの所在を問い合わせるため、開始ゲートウェイ（Ｉｎｉｔｉａｔｉｎｇ Ｇａｔｅｗａｙ） にRegistry Stored query トランザクションを発行する。他のコミュニティにあるリポジトリ（Ｄｏｃｕｍｅｎｔ Ｒｅｐｏｓｉｔｏｒｙ）に対しては 開始ゲートウェイ（Ｉｎｉｔｉａｔｉｎｇ Ｇａｔｅｗａｙ） にRetrieve Document Set を発行して、ドキュメントを読み出す形となる。XDS.b のトランザクションに加えて、homeCommunityId の伝達が必要である。
E.1.1.2 開始ゲートウェイ（Initiating Gateway）
コミュニティ間のアクセスにおいては、コミュニティの内部アクタを代表し、コミュニティを出る全てのトランザクションを発行する機能をもつ 。ドキュメント利用者（Document
Consumer）から Registry Stored Query と Retrieve Document Set を受信する。ローカ
ルな（自分のコミュニティ内の）レジストリ(Document Ｒｅｇｉｓｔｒｙ)とリポジトリ(Document
Repository)にトランザクションを伝えると同時に応答ゲートウェイ（Responding Gateway）に接続して、Gross Gateway Query と Cross Gateway Retrieve を送り、他のコミュニティと通信する。
E.1.1.3 応答ゲートウェイ（Responding Gateway）
コミュニティに外部から入ってくる全てのトランザクションの唯一の接続ポイントとなるゲートウェイである。入ってくるトランザクションをコミュニティ内のローカルアクタに伝達する。応答ゲートウェイ（Ｒｅｓｐｏｎｄｉｎｇ Ｇａｔｅｗａｙ） をもつコミュニティが全てＸDS
AFFINITY DOMAIN(XAD)の構造をもっているとは限らないが、ＸＡＤの場合は、レジス
トリやレポジトリに対してＲｅｇｉｓｔｒｙ Ｓｔｏｒｅｄ Ｑｕｅｒｙまたは、Ｒｅｔｒｉｅｖｅ Ｄｏｃｕｍｅｎｔ Ｓ
ｅｔを発行する。
E.1.2 XCA トランザクション
表 E-１に XCA のトランザクションを掲げる。
E.1.2.1 Cross Gateway Query[ITI-38] トランザクション
開始ゲートウェイ（Initiating Gateway） から応答ゲートウェイ（Responding Gateway）への問い合わせを行うトランザクションである。コミュニティ内では、Registry Stored Queryに相当する。

86

地域医療連携情報システム構築ハンドブック 201１ 附属書E.1.2.2 Cross Gateway Retrieve[ITI-39]トランザクション
開始ゲートウェイ（Initiating Gateway） から応答ゲートウェイ（Responding Gateway） に問い合わせ結果を要求するトランザクションである。コミュニティ内では、 Retrieve
Document Set に相当するトランザクションである。
表 E-1 XCA トランザクション
アクタ

トランザクション

Initiating Gateway

Responding Gateway

必須（R）／
オプショナル（O）

Vol.2内の節

Cross Gatway Query [ITI-38]

R

ITI TF-2b: 3.38

Cross Gateway Retrieve [ITI-39]

R

ITI TF-2b: 3.39

Registry Stored Query [ITI-18]

O

ITI TF-2a: 3.18

Retrieve Document Set [ITI-43]

O

ITI TF-2b: 3.43

Cross Gateway Query [ITI-38]

R

ITI TF-2b: 3.38

Cross Gateway Retrieve [ITI-39]

R

ITI TF-2b: 3.39

E.2 トランザクションのオプションとアクタのグループ化
表 E-２にトランザクションのオプションを掲げる。開始ゲートウェイは、Asynchronous
web service はオプションとなっている。一方応答ゲートウェイは Asynchronous web
service は実装する必要がある。
表 E-2 XCA トランザクションオプション
アクタ
Initiating Gateway

Responding Gateway

オプション

Vol＆節

XDS Affinity Domain Option

ITI TF-1: 18.2.1

Asyschronous Web Services Exchange

ITI TF-1: 18.2.2

No options defined--

図 E-２には開始ゲートウェイ（Initiating Gateway）とドキュメント利用者（Document
Consumer）をひとつのグループとして実装した例をあげる。これによりコミュニティ内のレジストリ、リポジトリへの問い合わせを効率化できる。このようなグループ化は応答ゲートウェイにおいても行うことが可能である。

87

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 E-2 アクタのグループ化実装

E.3 homeCommunityId
homeCommunityId は、コミュニティにユニークにつけられた ID である。不透明な場合もある（内部がはっきりとはわからない）コミュニティのＩＤも含まれる。オリジナルな医療情報をもつところにマッピングするために開始ゲートウェイ（Initiating Gateway）で使われる。Registry stored queries でのオプショナルパラメータとなる。同様に Retrieve
Document Set トランザクションのオプショナルパラメータにもなる。
E.4

シナリオ例

図 E-３及び図 E-４に利用シナリオ例の相互相関図をあげる。
[1] コミュニティＡの Document Consumer は、patient id を指定する形で Registry Stored
Query 要求を開始する。PDQ, PIX などの統合プロファイルを用いることにより、
XAD の patient id が確認されていることが前提である。この要求を受けて、Initiating Gateway は、patient id を指定して Registry Stored Query トランザクシ
ョンを処理する。Initiating Gateway は、どの Responding Gateways に要求を送るか、
あるいは、どの patient id を Cross Gateway Queries で用いるかを判断する(ただしこれはスコープ外である)。

88

地域医療連携情報システム構築ハンドブック 201１ 附属書

Community B(Remote)Community A (L ocal)
D oc
Con su m er

D oc Regi stryI n i ti ati n g G W

Registr y Stor ed
Pati ent
Quer yBy patient I d I dmappi ng

R espon di n g
GWCommunity C (Remote)
R espon di n g
GW

D oc R egi str y

Registr y
Stor edQuer yBypatient
Id

Cr ossGW
Quer yRegist er
Stor edQuer yQuery Access Remote
Communities
Regist r y
Stor edQuer yBy patientId

Cr oss GW Quer y
Response i ncl ude
homecCommuni ty i d-C

Reuse a r ecei ved
homeCommuni ty I d-C
Response i ncl ude
homeCommuni ty
I d-,B& AC
Registr y Stor ed
Quer y by U U I D

Use homeCommuni ty I d-C to
get to the Respondi ng Gateway

Regist r y Stor ed
Quer y by U U I D

Cr oss GW Quer y

Response i ncl ude
homeCommuni ty I d-C

Response i ncl ude
homeCommuni ty I d-C

D oc R egi str y

UUID
Refinement Query by
UUID to Communities

図 E-3 XCA シナリオ相互作用図 前半
Community A (L ocal)
D oc Con su m er

D oc R egi str y

Community C (Remote)Community B (Remote)I n i ti ati n g G W

Respon di ng G W

D oc Regi stry

Respon di ng G W

Use homeCommuni ty I d-C to
get to the Respondi ng Gateway
Registr y Stor ed
Quer y by U U I D
Reuse a r ecei ved
homeCommuni ty I d-C

Cr oss GW Quer y
Response i ncl ude
homeCommuni ty I d-C

Response i ncl ude
homeCommuni ty I d-C

Reuse a r ecei ved
homeCommuni ty I d-B& C

D oc
Reposi tor yRegistr y
Stor edQuer yByU U I D

UUIDRefinement Query by
UUID to Communities
Use homeCommuni ty I d-C to
get to the Respondi ng Gateway

Retr ieve D ocument
Set w ith
homeCommunity I dB& C
Use homeCommuni ty
I d-B to get to the
Respondi ng Gateway

D oc Regi stryCr oss GW Retr ieve

Cr oss GW
Retr i eve

R etr i eve D ocument
Set

D oc
Repositor y
Retr i eve
D ocument Set

図 E-4 XCA シナリオ相互作用図 後半

89

Retrieve Documentsfrom Remote
Community B and C

地域医療連携情報システム構築ハンドブック 201１ 附属書[2] Responding Gateway は、patient id で Cross Gateway Query を受ける。Responding
Gateway は Cross Gateway Query を処理し、Ｄｏｃｕｍｅｎｔ Ｃｏｎｓｕｍｅｒアクタとグ
ループ化されている場合であれば、コミュニティＢ内のレジストリに Registry Stored
Query を出す。レジストリからの応答情報を更新し、 homeCommunityId が指定されたことを確認し Cross Gateway Query への応答として返す。
[3] Initiating Gateway は Cross Gateway Query に対する応答を受ける。Initiating
Gateway は接続できた全ての Responding Gateways からの応答を集める。 それ
ぞ れ の 応 答 に 対 し て 、 homeCommunityId が 存 在 し て い る こ と や 、
homeCommunityId と Responding Gateway の間の関連情報を保存する。Initiating
Gateway が Registry Stored Query を自分のレジストリに出し、コミュニティのhomeCommunityId を含むように応答を更新する。全ての応答が受信できるとInitiating Gateway は応答データを Ｄｏｃｕｍｅｎｔ Consumer への応答として統合した形で返信する。
[4] Document Consumer は patient id による問い合わせ応答を Initiating Gateway より
受 信 す る 。 そ の 中 で １ ） homeCommunityId が 特 定 さ れ た こ と 、 ２ ） Document
Consumer は直接リポジトリ id をマッピングできないかもしれないこと、を確認する。
共通のコード、ボキャブラリーが全てのコミュニティで使われていなければならない。
特にプライバシー同意など。Document Consumer は homeCommunityId を保持しておく。
[5] Document Consumer は Registry Stored Query を UUID で発行する。Registry
Stored Query は patient id ではなく UUID をパラメータにもつ。
[6] Initiating Gateway は Registry Stored Query by UUID を処理する。どの Responding
Gateway と通信するかなど。
[7] Responding Gateway は Cross Gateway Query by UUID を処理する。コミュニティ内のレジストリに Registry Stored Query を発行する。
[8] Initiating Gateway は Cross Gateway Query の結果を受ける。この場合には応答をひとつだけ受け付ける。各コミュニティからの応答を統合することはしない。
[9] Document Consumer は Registry Stored Query の結果を受ける。
[10] Document Consumer は Retrieve Document Set を発行する。
Registry Stored Query by patient id あるいは by UUID によって１）ドキュメントのunique ID、2）リポジトリの unique ID、3)homeCommmunityId を指定して Retrieve
Document Set を出す。
[11] Initiating Gateway は Retrieve Document Set を処理する。Initiating Gateway はCross Gateway Retrieve を各コミュニティに発行する。結果は統合する。
[12] Responding Gateway は Cross Gateway Retrieve を発行する。XDS のコミュニティ

90

地域医療連携情報システム構築ハンドブック 201１ 附属書であれば、リポジトリに Retrieve Document Set トランザクションを出す。複数のリポ
ジトリの指定があれば、Responding Gateway は複数のリポジトリよりドキュメントを取得し、統合する。
E.5 セキュリティ要求事項
セキュリティに関するリスクを緩和するための要求事項として以下があげられている。
M1: すべての XCA アクタは ATNA ノードアクタ、CT クライアントとグループ化されなけ
ればならない。
M2: ドキュメントメタデータは SHA1 でハッシュすること。
M3: Document Consumer の実装は、応答データの過大なボリュームをローディングする際に、ソケットの読み出しを中断しクローズするなどにより対応できなければならない。 Initiating and Responding Gateways は応答プロセスの中断に対応しなけ
ればならない。
M4: Document Consumer の実装では、患者が特定されない Registry Stored Query を発行してはいけない。患者 ID かユニークなドキュメントエントリの ID かのいずれかである。
M6: わからない患者 ID のクエリーはゼロのドキュメントを返すこと。このことは患者 ID が正しくフォーマットされている場合もそうでない場合にも適用される。患者 ID のフォーマットが異常な場合のエラーコードを定義しないことで、アプリケーションが手探りでデータをさがすような機能を抑えることができる。
以下はオプショナルな要求である。
M5: DSG でディジタル署名をおこなう。
以下のリスクの軽減策はベンダとＸＡＤと施設に伝えられるべき内容である。
T1: レジストリメタデータ、リポジトリドキュメントと Gateway の設定のバックアップシステ
ム。
T2：全ての受信データは衝突なく、完全なデータが適切に伝送されること、またはエラーが出ることを確認できるように実装されることが推奨される。
T3: サービスの消滅攻撃に対抗できるようなネットワークの保護サービスが推奨される。
T4: 監査証跡がレビューできるプロセスと不適当なアクセスにアクションがとれるプロセスが推奨される。
T5: 衝突やサービス消滅攻撃がないようにサービスインターフェースをつけることが推
奨される。

91

地域医療連携情報システム構築ハンドブック 201１ 附属書

E.6 NAV との関連
ＸＣＡプロファイルにより、コミュニティ間のアクセスが可能になったため、NAV(Ｎｏｔｉｆｉｃａｔｉｏｎ ｏｆ Ｄｏｃｕｍｅｎｔ Ａｖａｉｌａｂｉｌｉｔｙ)プロファイルも、homeCommunity Id の情報への対応を行う。
E.7 XDS の構造を持たないコミュニティとの連携
XCA 統合プロファイルは広く連携ネットワークを接続する仕様としても検討されている。
以下、XDS 構造を持たないコミュニティとの連携など、いくつかの具体例をあげる。
E.7.1 XAD 間の連携例
図 E-５は、相手先のコミュニティが XAD である場合の連携例を示す。ただし、このような実装を規定するものではない。

図 E-5 相手が XDS Affinity Domain (XAD)の場合

E.7.2 nonXDS コミュニティとの連携
図 E-６は、相手先のコミュニティの構造が XDS ではない場合の連携例である。応答ゲートウェイから先は独自プロトコルとなる。

92

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 E-6 相手が nonXDS domain の場合

E.7.3 XDS コミュニティの集合体である場合の連携
図 E-７は、相手先が複数の XAD であるが、その中は見えない場合である。ひとつの応答ゲートウェイが２つのコミュニティをサービスしている。２つのコミュニティは開始コミュ
ニティ側からは見えないようになっているケースである。
E.7.4 nonXDS コミュニティの集合体である場合の連携
図 E-８は、相手先が複数の nonXAD である場合の連携である。図 E-７の場合と同様に
相手先コミュニティは開始コミュニティからは見えない。
E.7.5 透明な XAD である場合の連携開始ゲートウェイとレジストリがグループ化、応答ゲートウェイとレジストリがグループ化されているケースである。Document Consumer は自分のコミュニティからも相手先のコミュ
ニティからも自由にアクセスでき、中間に Cross Gateway Query などのトランザクションが入っていることにも気づかないで処理が進められる。開始ゲートウェイはプロキシリポ
ジトリのように振る舞うことになる。

93

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 E-7 相手が XAD の集合である場合

図 E-8 相手が nonXDS の集合の場合

94

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 E-9 透明な XAD の場合

95地域医療連携情報システム構築ハンドブック 201１ 附属書

附属書 F.

XCA-I 概説

XCA プロファイルは、コミュニティ（共通のポリシに合意した医療機関の集合、XDS アフィニティドメイン(XAD)とも呼ばれる）間でドキュメントを共有するための手段を提供するものである。トランザクションは XDS.b 統合プロファイルのものを前提としている。コミュニ
ティは homeCommunityId でグローバルに特定される。どのコミュニティに属するかについての制限はない。またコミュニティとしては必ずしも XDS があることは想定していな
い。
XCA-I 統合プロファイルは、XCA の仕組みで特定された画像マニュフェストに書かれた画像情報にアクセスする手段を提供する。本プロファイルの解説に当たっては、XCAの理解が前提となっている。
なお、本解説は、以下の版に基づいている。
IHE Radiology Technical Framework Supplement Cross-Community Access for
Imaging (XCA-I) Trial Implementation May 17, 2011
F.1 統合プロファイルの依存関係
XCA-I 統合プロファイルは表 F-1 に掲げられたプロファイルと関係している。すなわち、
XCA-I は、XDS.b、XCA の構成の上に記述された統合プロファイルであり、かつ
ATNA,CT といったプロファイルによりセキュリティを確保する必要がある。
表 F-1 プロファイルの依存関係
Cross-Communitiy Acess for
Imaging (XCA-I)

XDS.b
XCA

ATNA
incl.Radiology
Audit Trail
OptionCT

Required for access of
documents
Required for crosscommunity access of
documents
Each XCA-I Actor shall begrouped with Secure Node
Actor or Secure
Application.
Each XCA-I Actor Shall begrouped with the Time
Client Actor.

Required to manage audit
trail of exprted PHI, node
authenticationandtransport encryption.
To ensure consistency
among document andsubmission set dates

F.2 XCA-I アクタとトランザクション
図 F-2 にアクタとトランザクションを掲げる。アクタが灰色に塗られているのは、本統合
プロファイルのアクタではないが関係を明らかにするために書かれている。
F.2.1 XCA-I アクタ
以下に XCA-I のアクタを解説する。

96

地域医療連携情報システム構築ハンドブック 201１ 附属書F.2.1.1 開始画像ゲートウェイ（Initiating Imaging Gateway）
画像ドキュメント利用者（Image Document Consumer） から応答画像ゲートウェイ（Responding Imaging Gateway）への Imaging Document Set Retrieve 要求に対して、相手のコミュニティに Cross Gateway Retrieve Imaging Document Set トランザクションを出す。
F.2.1.2 応答画像ゲートウェイ（Responding Imaging Gateway）
開始画像ゲートウェイ（Initiating Imaging Gateway） から画像ドキュメントソース（Imaging
Document Source）へ Cross Gateway Retrieve Imaging Document Set 要求に対して、相手のコミュニティに Image Document Set Retrieve 要求を出す。
F.2.2 XCA-I トランザクション
表 F-１にはトランザクションのリストをあげる。
F.2.2.1 Cross Gateway Retrieve Imaging Document Set[RAD-75]
Retrieve Imaging Document Set[RAD-69] トランザクションを相手のコミュニティに対して行う。
F.2.2.2 Retrieve Imaging Document Set[RAD-69][RAD-69]は、XDS-I.b では、Imaging Document Consumer が Imaging Document
Source にアクセスするトランザクションであるが、XCA-I では、Imaging Document
Consumer が Initiating Imaging Gateway にアクセスするトランザクションになる97

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 F-１ XCA-I アクタとトランザクション
表 F-2 XCA-I トランザクション
アクタ

トランザクション

Imaging Document Consumer

Retrieve Imaging Document Set

オプション

Vol＆節

R

RAD TF-3: 4.69

R

RAD TF-3: 4.69

R

RAD TF-3: 4.69

[RAD-69]
Imaging Document Source

Retrieve Imaging Document Set[RAD-69]

Initiating Imaging Gateway

Retrieve Imaging Document Set[RAD-69]

F.2.2.3 XCA-I オプション
表 F-5 にトランザクションのオプションを掲げる。オプションとして Asynchronous Web
Service があげられている。Responding Imaging Gateway トランザクションではオプション
指定ではなく、必須となっている。
表 F-3 XCA-I のトランザクションのオプション
アクタ

オプション

Vol＆節

Imaging Document Consumer

Asynchronous Web services

Vol 3, sec.4.69.4.3

Initiating Imaging Gateway

Asynchronous Web Services

Vol 3, sec. 4.75.4.2

98

地域医療連携情報システム構築ハンドブック 201１ 附属書Vol 3, sec.4.69.4.3
Responding Imaging Gateway

No options defined

Imaging Document Source

Asynchronous Web services

Vol 3, sec.4.69.4.3

F.3 ユースケース
ユースケースとして地理的に広がった地域で、多くのコミュニティが立ち上がっているところを想定する。それぞれのコミュニティは、XDS のインフラをもっており、レポートと画像のマニフェストを共有している。ドメインは、共通の患者 ID とコード化された用語をもっている。この中の２つのコミュニティが救急患者対応についてドキュメント共有を行う。
ある患者が自ら登録されているドメインと異なったドメインの医療機関で救急治療を受けることになった。画像検査をオーダしようとした医師は院内の PACS にアクセスする。
すでに 行った 画像検査を取得するた めである。ここでは院内 PACS が Imaging
Document Consumer として自動的に自らの登録コミュニティとさらに連携している別のコミュニティへ検索を行う。XDS.b の Stored Query トランザクションを Initiating Gatewayに出す。Initiating Gateway は、自らのコミュニティのレジストリへ問い合わせると同時に、別のコミュニティの Responding Gateway に問い合わせる。院内 PACS は Imaging
Document Consumer として同じコミュニティの医療機関の Imaging Document Source にアクセスする。他のコミュニティの画像は、Initiating Gateway が Responding Gateway ア
クセスすることで取得する。
図 F-2 に相互作用図の例を掲げる。

99

地域医療連携情報システム構築ハンドブック 201１ 附属書IHE Radiology Technical Framework Supplement – Cross-Community Access for Imaging(XCA-I)______________________________________________________________________________

355

Figure 29.3.2-1
XCA-I Detailed
Interactions
図 F-2 XCA-I
相互作用図

Query across Local Community A and Remote Community: Document Consumer initiates[1]a Registry
自分のコミュニティ(Local)Aとする。Document
Stored Query request byと相手先のコミュニティ(Remote)B
patient id – the Document Consumer initiates
the initialtransaction
by formatting
a Registry
Stored Queryrequestby patient
identifier.
The consumer
Consumerは patient
id によってRegistryStoredQuery
要求を開始する。
360
uses PDQ, PIX or some other means to identify the Local Affinity Domain patient id, formats
はplus
PDQ,PIX
Local
id requestを特定する。こthatConsumer
information
any otherなどによって自分のコミュニティのquery parameters into a Registry Stored
Query
and sends
thisれをrequestto an Initiating
Initiating
GatewayGateway.
に送る。
Gateway
processes
RegistryidStored
QueryRegistryby patientStored
id request– Theを処理する。
Initiating[2]Initiating
Initiating
Gatewayは patient
によって
Query
Gateway receives a Registry Stored Query by patient id and must determine
Initiating Gateway はどの Responding Gateway に送るか、Cross Gateway Query で
365a) Which Responding Gateways this request should be sent to
どの id を用いるかを決める。また自分のコミュニティのレジストリにも Registry Storedb) What patient id to use in the Cross Gateway Queries. Detailed specification of these steps is
Query
を出す。
not in theintended scope of this profile. Combination of this profile with other existing[3]__________________________________________________________________________
Responding Gateway は patient id で Cross Gateway Query を処理する。Responding
14 Stored Query を出す。Responding Gateway
Gateway は自分のレジストリに RegistryRev.
– 2011-05-17
Copyright © 2011: IHE International, Inc.
は1.1homeCommunityIdが明記されたことを確実にするため、レジストリからの応答を更新する。更新された応答は Cross Gateway Query への応答となる。
[4] Initiating Gateway は Cross Gateway Query by patient id 応答を処理する。
Initiating Gateway は、接続した全ての Responding Gateway からの応答を集める。

100

地域医療連携情報システム構築ハンドブック 201１ 附属書それぞれの応答には homeCommunityId が付与されている。Initiating Gateway は応答を統合し、ひとつの応答として Document Consumer に送る。
[5] Document Consumer は Registry Stored Query by patient id 応答を受ける。
homeCommunityId がわかっているか、相手先のコミュニティにあるリポジトリの UID
がマップできるかどうかを確認する。
[6] 画像マニュフェストとレポートの呼び出しを行う。Document Consumer は Retrieve
Document Set を発行する。 Registry Stored Query の応答は１）ドキュメントのID,2)Location の UID, 3)homeCommunityId である。Document Consumer はこれ
らのパラメータをセットして Retrieve Document Set トランザクションを Initiating
Gateway に送る。
[7] Initiating Gateway は Retrieve Document Set を処理： 多くの Responding Gatewayに Cross Gateway Retrieve 要求を出す場合もある。
[8] Responding Gateway は Cross Gateway Retrieve を処理する。自分のコミュニティの（複数の）Document Repository に Retrieve Document Set を出す。
[9] 相 手 先 コ ミ ュ ニ テ ィ （ Remote ） か ら 画 像 を 取 得 す る 段 階 で Imaging Document
Consumer は Retrieve Imaging Document Set を発行する。Retrieve Document Set
は画像マニュフェストを提供する。さらに 1)Imaging Document Source の Location
UID ２）Imaging Document Source 内のドキュメントの ID ３）DICOM 転送構文
UID, 4) Study Instance UID, 5)Series Instance UID, 6) homeCommunityID の属性をもとに Retrieve Imaging Document Set を組み立てる。
[10] Initiating Imaging Gateway は Retrieve Imaging Document Set を処理する。
[11] Responding Imaging Gateway は Cross Gateway Retrieve Imaging Document Setを処理する。
F.4 セキュリティ要求事項
セキュリティに関するリスクを緩和するための要求事項として以下があげられている。
M1: すべての XCA—I アクタは ATNA ノードアクタ、CT クライアントとグループ化されなければならない。
M2: Imaging Document Source は[RAD-６９]の応答で SHA1 ハッシュを行うこと。
Imaging Document Consumer は SHA1 ハッシュを処理できること。
M3: Imaging Document Consumer の実装は応答データの過大なボリュームをローディングする際に、ソケットの読み出しを中断しクローズするなどにより対応できなければならない。 Initiating and Responding Imaging Gateways は応答プロセスの中断に対応しなければならない。
M6: わからない患者 ID のクエリーはゼロのドキュメントを返すこと。このことは患者 ID が正しくフォーマットされている場合もそうでない場合にも適用される。患者 ID のフォ

101

地域医療連携情報システム構築ハンドブック 201１ 附属書ーマットが異常な場合のエラーコードを定義しないことで、アプリケーションが手探りでデータをさがすような機能を抑えることができる。
以下はオプショナルな要求である。
M5: DSG でディジタル署名をおこなう。
以下のリスクの軽減策はベンダとＸＡＤと施設に伝えられるべきである。
T1: レジストリメタデータ、リポジトリドキュメントと Gateway の設定のバックアップシステ
ム。
T2： 全ての受信データは衝突なく、完全なデータが適切に伝送されること、またはエラーが出ることを確認できるように実装されることが推奨される。
T3: サービスの消滅攻撃に対抗できるようなネットワークの保護サービスが推奨される。
T4: 監査証跡がレビューできるプロセスと不適当なアクセスにアクションがとれるプロセスが推奨される。
T5: 衝突やサービス消滅攻撃がないようにサービスインターフェースをつけることが推
奨される。

102

地域医療連携情報システム構築ハンドブック 201１ 附属書

附属書 G.

XCPD 概説XCPD（Cross-Community Patient Discovery：コミュニティ間での患者発見）
は XCA を補完する統合プロファイルであり、地域医療連携コミュニティ間での患者診療情報の検索を支援するプロファイルである。具体的にはコミュニティ
間で該当患者の診療情報があるコミュニティを探し出し、これらの診療情報が見つかったコミュニティ間で該当患者の患者 ID の交換を行う。
本附属書では、XCPD の概要を文献[1]に沿って説明する。
G.1 アクタとトランザクション
XCPD は２つのアクタおよび２つのトランザクションから構成される。アクタとトランザクションの関係は図 G-1 の通り。

図 G-1 XCPD のアクタとトランザクション

G.1.1 アクタ
XCPD を構成するアクタを表 G-1 に示す。アクタの名称が XCA と同じである
が、必ずしも XCA の該当するアクタと一緒に実装する必要はない。
表 G-1 XCPD のアクタ
アクタ

概要

開始ゲートウェイ

コミュニティ内の患者に関する基本情報を外部のコミュニティに問い合（Initiating Gateway）

わせる。

応答ゲートウェイ

外部のコミュニティの開始ゲートウェイからの患者基本情報の問い合わ（Responding Gateway）

せに対する窓口。自分のコミュニティ内で該当の患者が見つかった場合には、問い合わせ元の開始ゲートウェイに通知する。

103

地域医療連携情報システム構築ハンドブック 201１ 附属書G.1.2 トランザクション
XCPD を構成するトランザクションは表 G-2 の通り。また各アクタがサポートするトランザクションを表 G-3 に示す。
表 G-2 XCPD のトランザクション
トランザクション

概要

Cross Gateway Patient

開始ゲートウェイと応答ゲートウェイが互いに共通する患者を見つける

Discovery[ITI-55]

機能をサポートする。

Patient Location Query

特定の患者の医療情報を保持するコミュニティのリストを取得するため[ITI-56]のクエリをサポートする。

表 G-3 各アクタがサポートするトランザクション
アクタ

トランザクション

必要性

開始ゲートウェイ

Cross Gateway Patient Discovery[ITI-55]

R（Initiating Gateway）

Patient Location Query [ITI-56]

O

応答ゲートウェイ

Cross Gateway Patient Discovery[ITI-55]

R（Responding Gateway）

Patient Location Query [ITI-56]

O

さらにトランザクション[ITI-55]では、XCPD が利用される環境に応じて利用可
能な３つのモードがある。これらのモードを以下に示す。
（１）Demographic Query only mode
開始ゲートウェイからの要求メッセージに、開始コミュニティでの患者
基本情報だけが含まれる。開始ゲートウェイでは、応答ゲートウェイで使っている患者 ID を保持しない。
（２）Demographic Query and Feed mode
開始ゲートウェイからの要求メッセージに、開始コミュニティでの患者基本情報と患者 ID が含まれる。
（３）Shared/National Patient Identifier Query and Feed
開始ゲートウェイからの要求メッセージに、複数のコミュニティにおいて共通に利用可能な患者 ID あるいは国民 ID だけを含む。共通/国民 IDのマッチング処理を行うため、患者基本情報は不要。
一般に Cross-Community Patient Discovery[ITI-55]によるコミュニティ間での患者情報の照合はコストがかかるので、照合が成功した場合は、両サイドで照合の成功による成果が使用できることが重要である。そこで応答ゲートウェ
イは[ITI-55]によるリクエストに含まれる患者の情報が、応答コミュニティでの患者の情報と一致する場合はこれらを関連付けて応答ゲートウェイで保持する104

地域医療連携情報システム構築ハンドブック 201１ 附属書ことを許している。同様に開始ゲートウェイにおいても、これらの患者情報を関連付けて保存する（患者情報の相互関係）。
G.1.3 オプション
XCPD の各アクタをそれぞれ実装する際には、以下の表 G-4 に示すオプション
を選んで実装することができる。
表 G-4 アクタとオプション
アクタ

オプション

開始ゲートウェイ

Health data Locatior Option（Initiating Gateway）

Revoke Option
Asynchronous Web Services Exchange
Deffered Response

応答ゲートウェイ

Health data Locatior Option（Responding Gateway）

Revoke Option
Deffered Response

表 G-4 でのオプションの概要を以下に示す。
（１）Health Data Locator Option
このオプションをサポートする開始ゲートウェイは、トランザクション
Patient location Query[ITI-56]をサポートし、患者の医療情報が存在するコミュニティのリストを要求できるようにする。
また、このオプションをサポートする応答ゲートウェイは、ある患者の医療情報がどのコミュニティに存在するかの情報を収集し、他のコミ
ュニティの開始ゲートウェイからの Patient Location Query[ITI-56]を利用した問い合わせに対して、その情報を提供できるようにする。
（２）Revoke Option
XCPD では、Cross-Community Patient Discovery[ITI-55]に対して得られた患者情報の相互関係の保存を許している。このオプションは保存された患者情報の相関関係を無効化できるようにする。
このオプションをサポートする開始ゲートウェイでは、応答ゲートウ
ェイに対して両サイドにある患者情報の相関関係は無効であることを通知するために、[ITI-55]での Revoke メッセージを利用する。
また、このオプションをサポートする応答ゲートウェイでは、上述のRevoke メッセージを受け取れるようにし、患者情報の相互関係の無効化を実行する。
なお、Revoke メッセージの詳細は文献[1]の 3.55.4.3 節を参照すること。

105

地域医療連携情報システム構築ハンドブック 201１ 附属書（３）Asynchronous Web Service Exchange
このオプションをサポートする開始ゲートウェイはトランザクション[ITI-55]と[ITI-56]において、非同期 Web サービス交換に対応すること。
非同期処理は多数存在するコミュニティへの問い合わせを効率的に取り扱うために必要である。
なお、応答ゲートウェイでは非同期 Web サービス交換のサポートはオプションではなく必須であるので注意すること。
（４）Deferred Response
Asynchronous Web Services Exchange オプションでは遅延応答に対するいくつかのシナリオをサポートしているが、応答の遅延が数日ないし数週間に及ぶような環境はサポートしていない。こうしたケースではア
プリケーションによる管理とシステム再起動を通じたリカバリをサポートする必要があるが、Deferred Response オプションはこうした機能をサポートする。特にメッセージの相関関係の管理、アプリケーションレ
ベルでの受領通知および Deferred Response メッセージの送り先の決定をもサポートする。
なお、Deferred Response メッセージの詳細は文献[1]の 3.55.6.2 節を参照すること。
G.1.4 参照する標準・仕様類
XCPD ではトランザクションでの通信方式ならびにメッセージスタイルなどで既存の仕様を参照している。XCPD に取り入れられている既存仕様を表 G-5 に示す。
表 G-5 XCPD における参照標準・仕様
参照技術

使用場面

SOAP1.2

トランザクション間の通信

HL7V3 Edition 2008, Patient

トランザクション［ITI-55］の実装において参照される。なお、[ITI-55]

Administration DSTU,の実装時には ITI TF-2x: Appendix V に準拠する必要がある。

Patione Topic
HL7V3 Datatypes 2008

トランザクション[ITI-56]の実装において参照される。

Normative Editionの実装時には ITI TF-2x: Appendix V に準拠する必要がある。

なお、[ITI-56]

G.2 XCPD における処理の流れ
前節で示したように、XCPD は２つのトランザクションからなる。本節ではこれらのトランザクションでの処理を文献[1]でも取り上げられている２つのシナリオに沿って説明する。

106

地域医療連携情報システム構築ハンドブック 201１ 附属書G.2.1 シナリオ１・Peer-to-Peer
３つのコミュニティ A,B,C を考える。それぞれのコミュニティでは XDS に基づ
く地域医療連携ネットワークが構築されている。いまコミュニティ A にある医療施設に患者 P が訪れ、A に対して患者登録が行われたとする。また、この患者 P はかつてコミュニティ C に患者登録され、P の医療情報が C に保存されているとする。本節のシナリオでは、患者 P が A に登録した時、XCPD の Cross
Gateway Patient Discovery トランザクションを用いて、３つのコミュニティがどのように患者情報の連携を行っているかを説明する。
本シナリオにおける処理の流れ（シーケンス図）を図 G-2 に示す。図 G-2 にある「I＆RGateway」は、XCA および XCPD の開始ゲートウェイと応答ゲート
ウェイをグループ化したものを示す。ここでの XCPD 応答ゲートウェイは「Demographic Query and Feed」モードで実装されているものとする。

図 G-2 シナリオ１における処理の流れ(文献[1]の Figure.27.3.2.1-1 から引用)

107地域医療連携情報システム構築ハンドブック 201１ 附属書[1] ある患者がコミュニティ A で新規に登録され、Patient Feed が A の開始ゲートウェイに送信される。
[2] コミュニティ A の開始ゲートウェイは、患者 P がコミュニティ B でも登録されているかどうかを Cross Gateway Patient Discovery トランザクション
を用いて B の応答ゲートウェイに問い合わせる。コミュニティ B でのマス
ター患者インデックス（Master Patient Indices：MPI）を調べた結果、該当の患者が登録されていないことが分かった。したがって B の応答ゲート
ウェイは、該当の患者が未登録である旨を A の開始ゲートウェイに通知する。
[3] コミュニティ A の開始ゲートウェイは、患者 P がコミュニティ C でも登録されているかどうかを Cross Gateway Patient Discovery トランザクション
を用いて C の応答ゲートウェイに問い合わせる。
[4] コミュニティ C での MPI を調べた結果、患者 P が既に登録されていることが判明した。したがって C の応答ゲートウェイは、該当の患者が登録されていることを、C での患者 ID とともに A の開始ゲートウェイに通知する。
さらに A の開始ゲートウェイからの問い合わせ時に添付されていた、A での患者 ID を C で保存する。
[5] [4]で保存した患者 ID は、コミュニティ C からコミュニティ A に対して XCAの Cross Gateway Query を送信するときに参照される。
[6] その後、コミュニティ B 内のある医療施設において患者 P が B に登録された。この患者の医療データを得るべく、その施設にある XDS.b コンシューマから B の開始ゲートウェイに対して XDS.b レジストリへの Stored Queryを送信する。
[7] [6]の Stored Query を受け取ると、コミュニティ B の開始ゲートウェイは
Cross Gateway Patient Discovery トランザクションを用いてコミュニティ
A に患者 P が登録されているかどうかを問い合わせる。コミュニティ A での MPI を調べた結果、患者 P が既に登録されていることが判明した。した
がって A の応答ゲートウェイは、該当の患者 P が登録されていることを、Aでの患者 ID とともに B の開始ゲートウェイに通知する。さらに B の開始ゲートウェイからの問い合わせ時に添付されていた、B での患者 ID を A で保存する。
[8] また、コミュニティ B の開始ゲートウェイは Cross Gateway Patient
Discovery トランザクションを用いてコミュニティ C にも患者 P が登録されているかどうかを問い合わせる。
[9] コミュニティ C での MPI を調べた結果、患者 P が既に登録されていること

108

地域医療連携情報システム構築ハンドブック 201１ 附属書が判明した。したがって C の応答ゲートウェイは、該当の患者が登録されていることを、C での患者 ID とともに B の開始ゲートウェイに通知する。
さらに B の開始ゲートウェイからの問い合わせ時に添付されていた、B での患者 ID を C で保存する。
[10] [6]の患者がコミュニティ A、C 両方に登録されていたので、コミュニティ
B の開始ゲートウェイは A および C の応答ゲートウェイに対して XCA
Cross Gateway Query を送付する。コミュニティ A と C の応答ゲートウェ
イからそれぞれ XCA Cross Gateway Query に対する検索結果を受け取ると、
B の開始ゲートウェイでは返された検索結果をまとめて、[6]での XDS.b コ
ンシューマに渡す。
[11] コミュニティ A にある一つの施設の XDS.b コンシューマから、患者 P の医療情報を得るべく、A の開始ゲートウェイに対して Stored Query を送信する。
[12] コミュニティ A の開始ゲートウェイは、コミュニティ B、C での患者 P のID を保存している。しかし、B,C での患者 P の ID を保存してからしばら
く時間が経過している場合（数日、数か月あるいは数年）は、患者 P の患者 ID におけるコミュニティ間の相互関係を再確認する必要がある。そのため、A の開始ゲートウェイは B および C の応答ゲートウェイに対して Cross
Gateway Patient Discovery トランザクションを利用する。
[13] 相互関係を確認してから、コミュニティ A の開始ゲートウェイはコミュニ
ティ B,C の応答ゲートウェイに XCA Cross Gateway Query を送る。コミュニティ A の開始ゲートウェイでは B と C の応答ゲートウェイからそれぞれ XCA Cross Gateway Query に対する検索結果を受け取ると、これらの検索結果をまとめて、[11]での XDS.b コンシューマに渡す。
G.2.2

シナリオ２・ヘルスデータロケータの使用

前節のシナリオ１と同じく３つのコミュニティ A,B,C を考え、患者 P の前提条
件もまたシナリオ１と同じで考える。ただし、コミュニティ C が「ヘルスデー
タロケータ」であるとする。本節のシナリオでは、患者 P がコミュニティ A に登録した時、XCPD の Cross Gateway Patient Discovery トランザクションおよび HealthCare Location Query トランザクションを用いて、３つのコミュニ
ティがどのように患者情報の連携を行っているかを説明する。
本シナリオにおける処理の流れ（シーケンス図）を図 G-3 に示す。図 G-3 にある「I＆RGateway」は、XCA および XCPD の開始ゲートウェイと応答ゲート
ウェイをグループ化したものを示す。

109

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 G-3 シナリオ２における処理の流れ(文献[1]の Figure.27.3.2.1-2 から引用)[1] ある患者 P がコミュニティ A で新規に登録され、Patient Feed が A の開始
ゲートウェイに送信される。
[2] コミュニティ A の開始ゲートウェイは、患者 P がコミュニティ B でも登録されているかどうかを Cross Gateway Patient Discovery トランザクション
を用いて B の応答ゲートウェイに問い合わせる。コミュニティ B での MPIを調べた結果、該当の患者が登録されていないことが分かった。したがって
B の応答ゲートウェイは、該当の患者が未登録である旨を A の開始ゲート
ウェイに通知する。

110

地域医療連携情報システム構築ハンドブック 201１ 附属書[3] コミュニティ A の開始ゲートウェイは、患者 P がコミュニティ C でも登録されているかどうかを Cross Gateway Patient Discovery トランザクション
を用いて C の応答ゲートウェイに問い合わせる。
[4] コミュニティ C での MPI を調べた結果、患者 P が既に登録されていることが判明した。したがって C の応答ゲートウェイは、該当の患者が登録されていることを、C での患者 ID とともに A の開始ゲートウェイに通知する。
合わせて、C が患者 P に対する「ヘルスデータロケータ」であることも通知する。さらに A の開始ゲートウェイからの問い合わせ時に添付されていた、A での患者 ID を C で保存する。
[5] [4]で保存した患者 ID は、コミュニティ C からコミュニティ A に対して XCAの Cross Gateway Query を送信するときに参照される。
[6] その後、コミュニティ B 内のある医療施設において、患者 P が B に登録された。この患者の医療データを得るべく、その施設にある XDS.b コンシューマから B の開始ゲートウェイに対して XDS.b レジストリへの Stored
Query を送信する。
[7] [6]の Stored Query を受け取ると、コミュニティ B の開始ゲートウェイは
Cross Gateway Patient Discovery トランザクションを用いてコミュニティ
A に患者 P が登録されているかどうかを問い合わせる。コミュニティ A での MPI を調べた結果、患者 P が既に登録されていることが判明した。した
がって A の応答ゲートウェイは、該当の患者 P が登録されていることを、Aでの患者 ID とともに B の開始ゲートウェイに通知する。さらに B の開始ゲートウェイからの問い合わせ時に添付されていた、B での患者 ID を A で保存する。
[8] また、コミュニティ B の開始ゲートウェイは Cross Gateway Patient
Discovery トランザクションを用いてコミュニティ C にも患者 P が登録されているかどうかを問い合わせる。
[9] コミュニティ C での MPI を調べた結果、患者 P が既に登録されていることが判明した。したがって C の応答ゲートウェイは、該当の患者が登録されていることを、C での患者 ID とともに B の開始ゲートウェイに通知する。
さらに B の開始ゲートウェイからの問い合わせ時に添付されていた、B での患者 ID を C で保存する。
[10] 患者 P がコミュニティ A、C 両方に登録されていたので、コミュニティ Bの開始ゲートウェイは A および C の応答ゲートウェイに対して XCA Cross
Gateway Query を送付する。コミュニティ A と C の応答ゲートウェイからそれぞれ XCA Cross Gateway Query に対する検索結果を受け取ると、B の開始ゲートウェイでは返された検索結果をまとめて、[6]での XDS.b コンシ

111

地域医療連携情報システム構築ハンドブック 201１ 附属書

ューマに渡す。
[11] コミュニティ A にある一つの施設の XDS.b コンシューマから、患者 P の医療情報を得るべく、A の開始ゲートウェイに対して Stored Query を送信する。
[12] コミュニティ A のゲートウェイは、コミュニティ B、C での患者 P の IDを保存している。しかし、B,C での患者 P の患者 ID を保存してからしばら
く時間が経過している場合（数日、数か月あるいは数年）は、患者 P の ID
におけるコミュニティ間の相互関係を再確認する必要がある。そのため、Aの開始ゲートウェイは B および C の応答ゲートウェイに対して Cross
Gateway Patient Discovery トランザクションを利用する。
[13] 相互関係を確認してから、コミュニティ A の開始ゲートウェイはコミュニ
ティ B,C の応答ゲートウェイに XCA Cross Gateway Query を送る。コミュニティ A の開始ゲートウェイでは B と C の応答ゲートウェイからそれぞれ XCA Cross Gateway Query に対する検索結果を受け取ると、これらの検索結果をまとめて、[11]での XDS.b コンシューマに渡す。
参考文献[1] IHE IT Infrastructure Technical Framework Supplement:
Cross-Community Patient Discovery(XCPD) Trial Implementation, Rev.2.3,
August 19, 2011112

地域医療連携情報システム構築ハンドブック 201１ 附属書

附属書 H.

XDR 概説XDR(Cross-Enterprise Document Reliable Interchange )は、標準規格を基にして、医療機関の間で、信頼に基づいた point-to-point（１対１の）ネットワーク・コミュニケー
ションを用いて、Document の交換を実現する統合プロファイル（業務シナリオ）である。
本統合プロファイルも、EHR、PHR と他のヘルスケア IT システムの間でより良いinteroperability の提供に役立つことが期待されている。また、XDR は、情報共有基盤（Repository と Registry）が必要でない／用意できない場面において役に立つ、IHE ITI
XDS 統合プロファイルの補遺である。ドキュメントコンテンツは XDS と同じものを利用し、新規のメタデータも定義されていない。
本附属書では、XDR の概要を文献[1]に沿って説明する。
H.1 アクタとトランザクション
XDR は、2 つのアクタ Document Source、Document Recipient、及び 1 つのトランザクシ
ョン Provide and Register Document Set-b[ITI-41]から構成される。
H.1.1

アクタ

アクタ Document Source は、ドキュメントとそのインデックス情報（メタデータ）を提供する。
また Document Recipient は、Document Source から送られてくるドキュメントとメタデータを受信する。
H.1.2 トランザクション
トランザクション[ITI-41]は、Document Source から Document Recipient へのドキュメント
ならびにメタデータの送信手続きを定義する。
XDR を構成するアクタとトランザクションの関係を図 H-1 に、各アクタがサポートするトラ
ンザクションを表 H-1 に示す。

図 H-1 XDR のアクタとトランザクション
表 H-1 XDR の各アクタがサポートするトランザクション
アクタ
Document Source

トランザクションオプション

Provide and Register Document Set-b

R

113

Vol＆節
ITI TF-2:3.41

地域医療連携情報システム構築ハンドブック 201１ 附属書[ITI-41]
Document Recipient

Provide and Register Document Set-b

R

ITI TF-2:3.41[ITI-41]

H.1.3 オプション
XDR 統合プロファイルには、オプション機能は存在しない。
H.2

XDR における処理の流れ

XDR では医療従事者間で患者のドキュメントセットを交換する場合を記述している。
まだ、XDS が利用できない／準備できない環境において、XDR は有用な問題解決方
法となることが期待される。また、ある１人の患者に関係するドキュメントを、自動的に処理・保存し、簡易にアクセスできないような堅牢なシステムが構築されている状況においては、XDR は適切な統合プロファイルといえる。
XDR 統合プロファイルは、個人の医療ドキュメント交換を目的としており、すべての施設間での EHR の通信ニーズに対応するものではない。
以下に、本統合プロファイルのユースケースを示す。
H.2.1 シナリオ１
1. 医師プライマリ先生は、担当患者ロビンソンさんを、消化管専門医に紹介したいと考えている。消化管専門医のガストロ医師のクリニックとは XDS や XDS-MS を利用できる
環境にはない。またガストロ医師とプライマリ医師は、情報を共有できるほど（おなじAffinity Domain に所属するほど）信頼関係も存在しない。このような場合に、XDR 統合
プロファイルは、患者ロビンソンさんの照会情報の交換のために役立つことができる。
XDR は、ガストロ先生からプライマリ先生への逆報告の文書提供にも適切である。
H.2.2

シナリオ２

メイベルさんは、長期療養のために、病院から彼女の老人介護施設に移動する。
XDR を利用してメイベルさんの情報は、彼女担当の主治医と看護師によって病院から長期療養所の EHR に移管される。
H.2.3 シナリオ３
スタンリーさんの最近の MRI の結果が通常とは異なる状態だったので、主治医はがん専門に相談しようと考える。当院の遠隔診断ができる Affinity Domain には適当な医療機関が存在しない。XDR は XDS の代わりに診断依頼として利用することができる。

114

地域医療連携情報システム構築ハンドブック 201１ 附属書H.2.4 シナリオ４
佐糖夫人は成人糖尿病と診断される。彼女が受診した医療機関は、文書を共有できるような仕組み(XDS)が実現できていない環境である。XDS が実現されるまで、担当
医療機関は XDR を用いてピア・ツー・ピアの環境で彼女の情報を交換し合う必要があり、また、交換を実現できる。
参考文献[1]
IHE IT Infrastructure (ITI) Technical Framework Volume 1 (ITI TF-1),
Integration Profiles, Revision 8.0, August 19, 2011115

地域医療連携情報システム構築ハンドブック 201１ 附属書附属書 I. XDM 概説
XDM（Cross-Enterprise Document Media Interchange：媒体によるドキュメント共有）は、標準的なメディア媒体と、共通なファイルとディレクトリ構造を使用して、ドキュメント交換を提供する統合プロファイルである。XDM は XDS の補遺であり、XDS が”Publish andPull”型のコミュニケーションを提供する一方で、XDM では CD-R や USB メモリデバイス、ZIP ファイルを添付した E-Mail を利用して”Push”型のコミュニケーションを提供する。ドキュメントコンテンツは XDS や XDR と同じものを利用し、新規のメタデータも定義されていない。
本附属書では、XDM の概要を文献[1]に沿って説明する。
I.1 アクタとトランザクション
XDM は２つのアクタおよび１つのトランザクションから構成される。アクタとトランザクショ
ンの関係は図 I-1 の通りである。また、XDM を構成するアクタとサポートするトランザク
ションを表 I-1 に示す。

図 I-1 XDM のアクタとトランザクション
表 I-1 XDM の各アクタがサポートするトランザクション
アクタ
Portable media Creator

トランザクション
Distribute Document Set on Media

オプション

Vol＆節

R

ITI TF-2b:3.32

R

ITI TF-2b:3.32[ITI-32]
Portable Media Importer

Distribute Document Set on Media[ITI-32]

I.1.2 オプション
XDM の各アクタをそれぞれ実装する際には、以下の表 I-2 に示すオプションを選んで実装することができる。このうち CD-R、USB、ZIP over E-mail のオプションについては、
最低１つ以上のオプションを実装する必要があるが、相互運用性の確保のためには全てのオプションを実装することが望ましいとされている。

116

地域医療連携情報システム構築ハンドブック 201１ 附属書表 I-2 XDM の各アクタのオプション

表 I-2 でのオプションの概要を以下に示す。
(1) USB Option
USB Option では Portable Media Creator は、USB メディアにドキュメントセットを書き込む。メディアは物理的に運ばれ、ドキュメントセットは Portable Media Importer に取り込まれる。
(2) CD-R Option
CD-R Option では Portable Media Creator は、CD-R メディアにドキュメントセットを書き込む。メディアは物理的に運ばれ、ドキュメントセットは Portable Media Importer に取り込まれる。
(3) ZIP over E-Mail Option
ZIP over E-Mail Option では Portable Media Creator は、ドキュメントセット（複数可）を含む仮想的なメディアを通常の ZIP ファイルとして作成する。ZIP ファイルは、電子メー
ルに添付して Portable Media Importer に送られる。Portable Media Importer では、電子メールを受け取り、ドキュメントセットを含む ZIP ファイルを取り込む。
(4) ZIP over Email Response Option
ZIP over Email Response Option では、Portable Media Importer は、受信したドキュメン
トセットの取り込み操作に成功したことを確認するため、Portable Media Creator へのMDN に基づいた応答を送信する。このオプションをサポートする場合、電子メールオ117

地域医療連携情報システム構築ハンドブック 201１ 附属書

プションオーバーZIP がサポートされる必要がある。
I.2 XDM における処理の流れ
XDM では医療従事者間で患者のドキュメントセットを交換する場合を説明している。
XDS は、参加者一人との情報交換では望ましくない、あるいは利用できない。XDM は
このような場合に実行可能な選択肢である。
XDM は、情報の受け取り側が個人であり、物理メディアを使用しているように、手動でデータと関連文書を解釈し、分析する状況において、使用されるべきである。データは人間の介入によって手動で解釈されるため、XDM は複数患者のドキュメント交換が可能になる。
XDM 統合プロファイルは、個人の医療ドキュメント交換を目的としており、すべての施設間での EHR の通信ニーズに対応するものではない。いくつかのユースケースは、
XDS、DSG、PIX、および ATNA など、他の IHE 統合プロファイルを必要とする場合がある。他のユースケースについては、部分的にサポートされている可能性があり、将来のIHE 統合プロファイルを必要とする場合もある。
(1)シナリオ１
・Dr. Primary が、老齢の患者 Mr. Robinson を胃腸科専門医に初回予約するために照会をする。
Dr. Primary のオフィスと Dr. Gastro の診療所のどちらもセキュアな E-mail や http over
VPN など、他の持続的な 2 点間通信を処理することができない場所では、XDM プロフ
ァイルが物理的なメディア、または電子メールによる、より単純な環境を追加的なソリューションとして提供する。ここでは、交換するドキュメントセットを人間が介入することによって手動で解釈する。
(2)XDS の基盤を持っていない病院において、XDS-MS コンテンツプロファイルの退院
ユースケースは XDM によっても処理できる。
病院または強固な EHR を使用していない家庭医では、患者は CD や USB メディアに記録された退院時の情報を、フォローアップのために家庭医を受診する際に持参して手渡すことができる。
(3) Mabel は、病院から長期療養のための老人ホームに転送される。
病院が彼女の診療データを解釈して、必要な医療メンバと共有する EHR アプリケー
ションを持っていない場合には、情報は手動で直接、ファイルクラーク、受け入れコー
ディネータ、記録管理者、主治医などに施設の運用に合わせて送られる。

118

地域医療連携情報システム構築ハンドブック 201１ 附属書(4) Stanley の最近の MRI の結果に、これまでと異なる結果が出ており、Stanley の主治
医は、州内にある特殊ながん診療施設の別の専門家に相談したい。遠隔保健環境の間にはアフィニティドメインがないため、XDM を代わりに使用する。
(5) 情報に精通した患者 Bob は自宅で自分の Personal Health Record (PHR)のコピーを保持している。この状態で Bob は医療情報のコピーを CD-ROM などの物理メディアでもらい、持ち帰ることができる。もし新しい救急部門が彼のリポジトリへのアクセス権を持たないような場所への州外の旅行に行った場合でも、Bob は突然救急外来を受診するときに、利用可能な彼の完全な医療記録を持ち続けることができるという利点がある。
このプロファイルは、このようなユースケースで使用されるデジタル媒体を送る仕組みのみを定義している。内容については、IHE PCC（Patient Care Coordination）ドメインで定義されているような Content Profiles で詳述されている。
参考文献[1] IHE IT Infrastructure (ITI) Technical Framework Volume 1 (ITI TF-1), Integration
Profiles, Revision 8.0, August 19, 2011119

地域医療連携情報システム構築ハンドブック 201１ 附属書

附属書 J.

オープンソースの利用方法

本附属書では、地域医療連携情報システムの実装に参考になる IHE 関連技術のオー
プンソースについて紹介する。
J.1 概要これまで、さまざまな組織が IHE テクニカルフレームワークに従って XDS、PIX/PDQ などを実装してきた。これらの実装のうち、いくつかはオープンソースとして公開されている。これらのオープンソースは以下の点において期待できる。
・開発した各アクタの動作試験
・オープンソースをベースとしたシステム開発に利用可能
・地域医療連携システムを構築する上での参考となる
そこで本章では、公開されているオープンソースのうち、・IHE が公開しているスキーマファイル
・NIST XDS レジストリ・リポジトリ
・NIST XDS ツールキットを紹介する。さらに他のオープンソースに関する情報も提供する。
本附属書は実際に地域連携システムの開発を担当する技術者を対象とするが、Windows あるいは Linux の操作にある程度親しみ、オープンソースのインストール経験がある方であれば、実際にインストールし、動作させることができると思われる。興味のある方はお手持ちのマシンにぜひオープンソースをインストールし、動かして見ることをお勧めする。
なお、本書の内容は、2011 年 10 月現在の情報に基づく。
J.2 スキーマファイル
IHE では、XDS.b、XCA、XCPD、RFD、SVS、PIX(HL7ver.3)、PDQ(HL7ver.3)の開発に有用なスキーマファイル（XSD ファイル）や WSDL 定義ファイルを公開している。以下のFTP サイト（図 J-1）から取得できる。
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/packages

120

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 J-1 IHE スキーマファイル FTP サイト

このサイトにはさまざまな種類のファイルがあるが、XDS.b の各アクタを構築する場合は、このサイトから最新の XDSb.Support.Materials をダウンロードする。
ダウンロードしたファイルを適当なディレクトリで展開すると、そのディレクトリに examples、
schema、wsdl の 3 つのディレクトリができる。XSD ファイルは schema 以下に、WSDL 定
義ファイルは wsdl 以下にそれぞれ格納されている。これらの XSD ファイル、WSDL ファ
イルを利用して、各アクタのインタフェース部分を構築することができる。しかし他に必要となる各アクタの機能は、IHE テクニカルフレームワークに従い別途実装する必要がある。
J.3 NIST XDS レジストリ・リポジトリ
J.3.1 概要
本節では、アメリカ国立技術研究所(National Institute of Standards and Technology :NIST)により開発・公開されている XDS レジストリ・リポジトリを紹介する。これは、XDS のドキュメントレジストリ及びドキュメントリポジトリがインタフェース部分も含め、テクニカル121

地域医療連携情報システム構築ハンドブック 201１ 附属書

フレームワークに従って実装されたオープンソースである。また、XDS.b のほか、XDS.aにも対応している。
本オープンソースにより構築した XDS レジストリ・リポジトリサーバの概略を図 J-2 に示す。本サーバは Tomcat1 と Tomcat2 の 2 台の Tomcat サーバが連携して動作する。

図 J-2 XDS レジストリ・リポジトリ概略図

Tomcat2 側は ebXML に基づくレジストリ・リポジトリが実装されたオープンソースである
ebxmlrr のサーバとして動作する。なお ebxmlrr は ebXMLver2.0 に基づいて実装されている。
そのため Tomcat1 側では、XDS で定義されている処理と ebXML のバージョンの違いを吸収する処理を行う。具体的には以下を行う。
・ドキュメントソース及びドキュメントリポジトリとのインタフェース
・ドキュメントリポジトリ
・ドキュメントレジストリで行うメタデータ登録に関するすべての処理（ただしメタデータの保存は ebxmlrr で行う）
・ドキュメントコンシューマからストアドクエリを受け取ったとき、それに対応する SQL クエ
リを作成する（クエリの変換）。
XDS.b に対応するためのメタデータの形式変換（ebXMLver3.0 と ebXMLver2.0 との間のバージョンの違いによるメタデータの変換）。
J.3.2 あらかじめ必要となるツール
本オープンソースは Linux 上で動作し、インストールに際して以下のものが必要となる。
・Sun Java ：JDK1.5

122

地域医療連携情報システム構築ハンドブック 201１ 附属書・PostgreSQL 8
なお、Tomcat、Axis、ebxmlrr はダウンロードパッケージに含まれる。さらにソースコードを取得する場合は以下のツールも必要となる。
・ant
・Subversion（SVN）
J.3.3 ダウンロード及びインストール
オープ ン ソー スのダウ ンロ ード 及びイ ンス ト ールの方法 は、 以下 のサイ ト（ IheOs
Installation：図 J-3）に説明されている（ただし説明は英語である）。
http://ihexds.nist.gov/XdsDocs/opensource/install.html

図 J-3 IheOs Installation

上記マニュアルに沿ってインストールが終了したならば、PostgreSQL を起動している状
態で２つの Tomcat を起動させれば、外部からの要求待ち状態になる。
J.3.4 その他の機能
本節で紹介した XDS レジストリ・リポジトリには、本来のドキュメントレジストリ、ドキュメント
リポジトリとしての機能の他に、以下の機能もある。

123

地域医療連携情報システム構築ハンドブック 201１ 附属書（１）患者 ID の簡易割り当て機能
本節で紹介した XDS レジストリ・リポジトリにドキュメントの登録を行う場合、あらかじめWeb ブラウザなどで下記サイトにアクセスして患者 ID を取得しておく。ただし、下記サイトのアドレスにある<ホスト名>は XDS レジストリ・リポジトリをインストールしたマシンのホスト名である（IP アドレスでもよい）。Web ブラウザを動作させるマシンに XDS レジストリ・リ
ポジトリをインストールされている場合ならば localhost としてよい。
http://<ホスト名>:9080/xdstools/pidallocate 5
上記サイトにアクセスすると、図 J-4 のようにブラウザ上に表示される。

図 J-4 XDS 患者 ID 割り当てサイト

図 J-4 では AssigningAuthority のボタンが４つ用意されている。たとえば一番上のボタンを押下すると、ブラウザには図 J-5 のように表示される。図 J-5 にある「d6a1818b2cd9446^^^&1.3.6.1.4.1.21367.2005.3.7&ISO」が割り当てられた患者 ID と2011 年 10 月時点での最新版(ダウンロードファイル名：xds_06_09.tgz)をインストールして、患者 IDの割り当てサイトにアクセスすると、「例外」として web ブラウザ上に以下のメッセージが表示される。
javax.servlet.ServletException: サーブレットクラス
gov.nist.registry.xdstools.servlet.PidAllocateServlet を初期化中にエラーが発生しました。
さらに同じ web ブラウザ上にその「原因」として、
java.lang.NoClassDefFoundError: gov/nist/registry/common2/exception/XdsInternalExceptionと表示される。これは本来必要とされるパッケージがダウンロードしたものから欠落しているのが原因である。これを回避して図 J-4 を表示させるためには、/usr/local/tomcat1/webapps/xdstools/WEB-INF/lib に xds-common.jar と xdsLog.jar をコピーした上で、tomcat1 を再起動する。なお xds-common.jar と xdsLog.jar は/usr/local/tomcat1/webapps/LogReader/WEB-INF/lib に含まれている。
5124

地域医療連携情報システム構築ハンドブック 201１ 附属書なる。

図 J-5 患者 ID の割り当て

ドキュメント登録を行う利用者は、上記サイトから取得した患者 ID をドキュメントエントリ、
フォルダ、サブミッションセットの属性である PatientID として設定する。
また、この患者 ID はサーバ側のデータベースに保存され、ドキュメント登録実行時にレ
ジストリ側で行われるメタデータの検証での患者 ID のチェックで利用される。
（２）LogRoader
ドキュメントの登録・検索・取得処理の受付、実行において、XDS レジストリ・リポジトリサ
ーバはログを出力する。出力されたログはデータベースへ蓄積されるが、これらのログを閲覧するツールとして、LogReader が用意されている。任意の Web ブラウザにおいて、以下のアドレスへ接続する。
http://<サーバ名>:9080/LogReader
図 J-6 に LogReader 画面を示す。図の左側にログの一覧が表示され、その中から一つ選択すると、ログの詳細がブラウザの右側に表示される。

125

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 J-6 LogReader（３）XDS Viewer
XDS Viewer を利用することで XDS レジストリ・リポジトリへ登録されたメタデータを検索・閲覧が可能である。任意の Web ブラウザで以下のサイトへ接続する。
http://<ホスト名>:9080/xdstools/viewer
図 J-7 に接続直後にブラウザ上に表示されたものを示す。

図 J-7 XDS Viewer 初期画面

図 J-7 の画面で、接続先レジストリを選択し、検索条件として患者 ID、ユニーク ID、
UUID のいずれかを入力する。その後メタデータの種類（SS：SubmissionSet、Doc：126

地域医療連携情報システム構築ハンドブック 201１ 附属書

DocumentEntry、Fol：Folder）のボタンを押下すると、検索を開始する。検索の結果は
図 J-8 左下に一覧表示される（図 J-8 の表示は図 J-7 で「SS」ボタンを押下した時）。
表示項目にはいくつかのリンクがあるが、これらを押下するとリンクに応じた詳細情報
が図 J-8 右側に表示される。図 J-8 は図中左側にあるリンク「SS1」を押下したとき、図中右側に登録された SubmissionSet の属性値が表示されたときのものである。

図 J-8 XDS Viewer

J.3.5 Public Registry
NIST では、XDS レジストリ・リポジトリをオープンソースとして公開するだけでなく、サーバマシンにインストールして、Public Registry としてインターネット上に外部公開している。Public Registry はその利用に際して特別な手続きは必要なく、自由に利用できる。
そのため後述の XDS ツールキットで Public Registry にアクセスして各種動作を確認したり、開発したドキュメントソース及びドキュメントコンシューマの動作試験に利用したりすることができる。
Public Registry については、以下のサイトを参照のこと。下記サイトに Public Registry
へアクセスするためのエンドポイント URL が記載されている。
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Public_Registr
y_Server_Configuration127

地域医療連携情報システム構築ハンドブック 201１ 附属書J.4 XDS ツールキット
J.4.1 概要
XDS ツールキットは、XDS におけるドキュメントリポジトリ及びドキュメントリポジトリの動作試験を行う目的で公開されているテストツールである。試験対象となるアクタがドキュ
メントレジストリの場合、XDS ツールキットはドキュメントリポジトリ及びドキュメントコンシ
ューマの役割を持つ。またドキュメントリポジトリが試験対象となる場合は、XDS ツール
キットはドキュメントソース及びドキュメントコンシューマの役割を果たす。
J.4.2 あらかじめ必要となるツール
XDS ツールキットは Windows 及び Linux で動作し、Sun の Java（JDK1.5）があらかじめインストールされている必要がある。
ただし XDS ツールキットは bash-shell 上で動作するため、Windows 上で利用するには、以下のうちの一つを別途インストールしておく必要がある。
・cygwin・win-bash
・GNU bash for Windows
・そのほか Windows 上で動作する bash-shell ツール
J.4.3 ダウンロード及びインストール
任意の Web ブラウザで以下のサイトへアクセスする。
http://ihexds.nist.gov/XdsDocs/xdstoolkit/
上記サイトへアクセスすると、図 J-9 に示すファイルのリストが表示される。ファイル名
xdstoolkit_XX_YY.zip をクリックすると XDS ツールキットのダウンロードが始まる。なお2011 年 10 月 1 日時点での最新版は xdstoolkit_06_13.zip（図 J-9 の赤枠で囲んだ部分）である。そこで、以下の説明では xdstoolkit_06_13.zip に基づいて説明する。

128

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 J-9 XDS ツールキットダウンロードサイト

取得したファイル xdstoolkit_06_13.zip を任意のディレクトリ<TestDir>で展開する。このとき、<TestDir>に xdstoolkit_06_13 というディレクトリができる。あと環境設定、パラメー
タ設定、テスト実行方法などの詳細な説明がディレクトリ
<TestDir>/xdstoolkit_06_13/docs にある install.txt にあるので参照のこと。
J.4.4 テストに関する情報
XDS ツールキットが使用するテスト用データ、ならびにテスト用設定ファイルはディレク
トリ<TestDir>/xdstoolkit_06_13/testkit 以下にある。ディレクトリ testkit には 14 個のディレクトリがあり、その中の５つのディレクトリ example、selftest、server、testdata、tests にはさらに 5 桁の数字が名前となるディレクトリが複数含まれている。
これらのディレクトリにはそれぞれテスト用データならびにテスト用設定ファイルが含まれている。またディレクトリの名前となっている 5 桁の数字がテスト番号である。このテス
ト番号の意味は、以下の（１）、（２）で説明される。
（１）Test Description
個々のテスト番号が指すテストの内容が、テスト番号順に説明されている。2009-2010
年度のテストについては以下のサイト
http://ihewiki.wustl.edu/wiki/index.php/XDS_Test_Kit_2009-2010_Test_Descriptions
を参照のこと（2011 年 10 月現在で、2011 年度のテストが公開されていないので、2009-2010 年度のテストが公開されている最新の情報となる）。上記サイトでテスト番号12049 の説明がある部分を図 J-10 に示す。

129

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 J-10 Test Description（テスト番号 12049）（１）Test Requirements
各テストにおいて、どのアクタがテストの対象となっているか表す。以下のサイトにおいてはトランザクションごとに表としてまとめられている。
http://ihewiki.wustl.edu/wiki/index.php/XDS_Test_Kit_Test_Requirements
図 J-11 には、トランザクション Retrieve Document Set [ITI-43]において、その対象となるテスト番号、およびテストごとに試験対象となるアクタが表されている。テスト番号には Test Description へのリンクが張られており、テスト番号をクリックすることで該当のテストが説明されている場所へ遷移できるようになっている。

130

地域医療連携情報システム構築ハンドブック 201１ 附属書

図 J-11 Test Requirements（トランザクション Retrieve Document Set）

例としてテスト番号 12029（Accept Document Set – Single Document）では、リポジトリ(Repository)とソース・リポジトリ一体型(Src/Rep)で「R」となっているが、記号「R」は「必須（Require）」を表し、テスト 12029 の試験対象であることを指す。
また、ドキュメントソース（Doc Src）、ドキュメントコンシューマ（Doc Cons）及びドキュメン
トレジストリ（Registry）は空欄となっているが、これはテスト 12029 では、該当のアクタは試験対象でないことを表している。
表中の記号は「R」以外にも多様な記号が使われているが、記号の意味は上記サイト
中に説明されている（図 J-12）。

図 J-12 Test Requirements131地域医療連携情報システム構築ハンドブック 201１ 附属書J.5 他のオープンソース
本章で紹介したもの以外にも、地域連携システムの構築に利用可能なオープンソースが公開されている、そこで本節ではこれらを簡単に説明する。
J.5.1 OpenHealthTools が公開するオープンソース
OpenHealthTools（OHT）では、IHE テクニカルフレームワークに沿って PIX/PDQ、ATNA 及び XDS のサーバサイドを実装し、以下の名前でオープンソースとして公開している。
・openpixpdq
・openatna
・openxds
このうち、openatna と openxds はソースコードが Subversion（SVN）サーバ上で公開されている。従って取得のためにはあらかじめ Subversion クライアントツールのインストールが必要となる。
一方 OpenPIXPDQ はバイナリ版、ソースコード版の両方をダウンロードサイトから取得できるようになっている。
各オープンソースについての詳しい情報はそれぞれ、下記のサイトを参照のこと。シス
テムの構造やインストール方法まで幅広く記述されている。
・OpenPIXPDQhttps://openpixpdq.projects.openhealthtools.org/
・OpenATNA
https://openatna.projects.openhealthtools.org/
・OpenXDS
https://openxds.projects.openhealthtools.org/
J.5.2

CodePlex

CodePlex はマイクロソフト社が運営する開発プロジェクトのホスティング web サイトである。この開発プロジェクトの一つとして XDS.b が実装され、オープンソースとして公開されている。詳細は下記サイトを参照のこと。
http://ihe.codeplex.com/
J.5.3 NHIN CONNECT
NHIN（National Health Information Network）はアメリカの国家医療情報ネットワークで、2005 年に開始された。NHIN CONNECT は医療機関などの組織の中で HIE（Health
Information Exchange：医療情報交換）の環境を簡単に構築するためのソフトウェアであり、NHIN のプロジェクトの一部として進められてきた。NHIN 及び NHIN CONNECT132

地域医療連携情報システム構築ハンドブック 201１ 附属書については本ハンドブックの別冊第 2 章に詳細に説明されているので、こちらを参照のこと。
NHIN CONNECT は 2009 年 2 月にアメリカ SSA（Social Security Administration：社会保険庁）が実際の業務環境に利用して成功を収め、同年 4 月にオープンソースとして公開された。以下のサイトには、CONNECT のダウンロードやインストール方法の説明のほかに、CONNECT に関する様々な説明がある。
http://www.connectopensource.org
J.5.4 Omar
NIST の XDS レジストリ・リポジトリ（J.3 参照）では、レジストリの中核部分として ebxmlrr
を利用しているが、これは ebXML ver2.0 に基づいて実装されている。しかし、ebXML
は現在 ver3.0 となっており、XDS.b で参照しているのはこのバージョンである。Omar（Object, Metadata and Artifacts Registry）はこの ebXML ver3.0 に基づいて実装されたオープンソースで、Sourceforge から公開されている（下記サイト）。
http://sourceforge.net/projects/ebxmlrr/files/
Sourceforge から公開されているものは java のソースコードであり、コンパイル、インストールの方法ならびに Omar に関するいろいろな情報は下記サイトから参照可能である。
・ http://ebxmlrr.sourceforge.net/
・ http://ebxmlrr.sourceforge.net/wiki/index.php/Main_Page （Omar wiki）
XDS.ｂに基づくレジストリの開発においては、レジストリの中核部分として Omar が利用可能である。ただしメタデータの検証、ストアドクエリの取り扱い、フォルダの属性
lastUpdateTime の更新など、XDS.b で規定されている処理については別途実装が必
要となる。

133

地域医療連携情報システム構築ハンドブック 201１ 附属書附属書 K.

IHE ポリシーTemplate など

本附属書では、本編の第６章で紹介した「TI User Handbooks」3 文書の内容を概説する。
各文書は、医療連携コミュニティ(XAD)構築時に行うべきポリシー作成やリスク分析、合意文書作成指針について記載されている。実際の構築時には、基本的認識事項として便利に利用できる。
K.1

医療連携コミュニティの構築

XADの構成医療連携コミュニティの構築

ーITI User Handbooksー
Cookbook,HIE Security & Privacy,Template
附属書 F1
本文4章で紹介した「 ITI User Handbooks」3文書の内容概説です。
各文書は、医療連携コミュニティ(XAD)構築時に行うべきポリシー作成やリスク分析、合意文書作成指針について記載されています。実際の構築
時には、基本的認識事項として便利に利用が出来ます。

Example XDS Affinity Domain Architecture

contents
1 Introduction
5 Conclusion
2 Scoping Security and Privacy
5.1 Future efforts
2.1 International Data Protection Principles
5.2 Building Today
2.2 Policies and Risk Management
2.3 Technical Security and Privacy controls
3 Applying Security and Privacy to an HIE
3.1 Patient Privacy Consent to participate in an HIE
3.2 Protecting different type of documents
3.3 Building Upon Existing Security Environment
3.4 IHE Security and Privacy Toolkit
4 IHE Security and Privacy Controls
4.1 Accountability Controls
4.2 Identification and Authentication Controls
4.3 Access Controls
4.4 Confidentiality Controls
4.5 Data Integrity Controls
4.6 Non-Repudiation Controls
4.7 Patient Privacy Controls
4.8 Availability Controls

IHE IT Infrastructure White Paper
HIE Security and Privacy through
IHE Profiles

Ver2.0 2008.Aug.22

134

地域医療連携情報システム構築ハンドブック 201１ 附属書

Policy environment

Introduction & Scope・ HIE(healthcare Information Exchange)は、複数医療機関が一人の患者の診療情報を長期に共有する仕組み。
・ ドキュメントは、単純なテキスト文書(Ex.PDF)や標準的構造文書(Ex.HL7 CDA)。
・ HIEの構成員は、基本的なセキュリティ原理を実装する必要がある。
・ HIEは、XDSを中心とするプロファイルで構成される。
・ IHE based HIEが、患者のプライバシーと情報セキュリティを守るため技術だけ
でなく、ポリシー定義が重要。
・ IHEのプロファイルは、相互運用性の確保に必要な技術的詳細の取決め。
Privacy and Security Polices、Risk Management、Operating Systems、
Healthcare Application Functionality、Physical Controls、general Network
Controlsについては触れていない。
・ Templateは概要を示す。

ポリシー環境は多層になっている

国際的レベル

国レベル

分野別レベル

個別組織レベル・ 本White Paperはプライバシとセキュリティのために、IHEプロファイルの使い方を示す。
・ Risk Management実施には本ガイドを取り入れることがシステム実装者の義務。

Policies

Policy Lifecycle

実システムでは多くのポリシーを調和させる必要がある。
a) アクセスできる資格とHIE文書b) HIEとしての提供できる文書
c) HIEとして受け入れられる文書タイプd) HIEとして受容可能なリスクレベルe) HIEポリシーの違反者への制裁f) 訓練と周知
g) 加入と脱退h) 非常時の運用
i) 許されるNW使用と防御j) 認証手段k) バックアップと回復l) 第三者の許容アクセスm) HIE情報の二次利用
n) HIEの可用性 (life critical, normal, or low priority)o) 保守p) HIEでのデータ保持期間
これらのポリシーは、対等ではなく上下関係がある。
(社会的一般規約 ⇒個別施設の規約 ⇒個々の事情による変更)

Technical Security and Privacy controls

Emergency Mode

・Emergencyの定義は広い
・Emergency時にポリシーを緩めることは合理的・Emergency時のポリシーは重要・Emergencyとはa) 自然・人的災害(例. Hurricane, Earth Quake)– 他地域からの応援救助者による迅速なアクセスb) ユーティリティの不調(例. 停電)– 無停電電源、バックアップ電源c) IT インフラの不調(例. hard drive crash)– 基本インフラ部分の冗長化d) 患者緊急時の特権的行為－ ブレークグラス(例.看護師による薬剤処方)e) 患者の顕著な危機に対してのアクセス防御の無視– ポリシーに明示されることで、ポリシー違反にあたらない
Policy同士の衝突があるが、表面的。
欧州では「人種」の記載は禁止されてるが、診療上は重要⇒ 「遺伝子情報の記録」として可とされる。

一般的なSecurity and Privacy controls はOECDの原則によって公表されている。
security and privacy controls には、下記のことが用いられる。
1) 責任管理（Accountability Controls）– 例: security audit logging, reporting, alerting and alarming.
2) 本人特定と認証(Identification and Authentication Controls)– 例: personal interactions, Digital Certificates, security
assertions, Kerberos, and LDAP.
3) アクセス制御(Access Controls)– 例: Role Based Access Controls.
4) 秘匿性（Confidentiality Controls）– 例:encryption or access controls.
5) 完全性(Data Integrity Controls)－ 例: digital signatures, secure hash algorithms, CRC, and checksum.
6) 否認防止( Non-Repudiation Controls)7) 患者プライバシ（Patient Privacy Controls）
8) 可用性(Availability Controls)－例: backup, replication, fault tolerance, RAID, trusted recovery,
uninterruptible power supplies, etc.

135

地域医療連携情報システム構築ハンドブック 201１ 附属書

例: OECD原則におけるデータ保護の2原則

Patient Privacy Consent(BPPC)◆安全管理の原則:◎見せるべきではない人には開示しない
・Identification and Authentication Controls.
・Access Controls.
・Confidentiality Controls.

・患者プライバシ管理◎無権限者による変更禁止
・Identification and Authentication Controls.
・Access Controls
このsecurity and privacy
・Data Integrity Controls.

◎必要時のアクセスの確保

controlsには、各種ポリシーによる入力が要る。
IHEプロファイルが適用できる

・Availability Controls◆責任の原則:◎行為主体者の確認

・Identification and Authentication Controls.

◎行為者と内容
・ Accountability Controls.

◎行為の否定不可・ Non-Repudiation Controls◆患者同意の標準はOASIS、HL7、ISO、ASTM等で開発している。
◆BPPCは拡張中であり粗いレベルだが、多くの場合で充分である。
HIEへのゲートキーパーになりうる。
◆BPPCによって可能になるポリシーは、• 明示的に Opt-In ：患者による HIEで使用可能な文書の選択• 明示的に Opt-Out ：患者による共有させない文書の選択• 暗黙的に Opt-In ：許される文書用途• 明示的に Opt-Out ：文書の公開• 明示的に Opt-Out ：通常時のケアのための文書共有• 明示的に Opt-Out ：非常時を含むケアのための文書共有• 明示的な取得認可 ：特別な研究用途• 同意ポリシーの変更• 公開しない直接利用• XCAによる文書使用の可能性• 明示的に Opt-in する個別ポリシー：各ケアイベントの都度• 明示的に特定のデータ利用

Access Control Policies の例

Authentication & Authorization

Mediated by Direct Care
ProviderResearch Information

X

Sensitive Clinical
Information

Administrative Staff

General Clinical
Information

Administrative Information

X

Functional Role

Dietary Restrictions

Billing Information

Sensitivity

EMR

Document Consumer
・Authentication
・Authorization
・Audit logging

Document
Registry

End User(Patient,Docter,Nurse)
BrowserDocument
Repository

Dietary Staff

X

X

General Care Provider

X

X

X

Direct Care Provider

X

X

X

X

X

Emergency Care Provider

X

X

X

X

X

Researcher

アクセス制御にはtopic of consent、confidentiality code、user、
functional role、situation などの要素があるがこれが全てではない。現在の標準規約とはギャップがある。
IHEはpilot projectを行い、Security and Privacy modelの拡張でギャップを埋めていく。

X

Patient or Legal Representative
X
X
X
X
X
XDS の文書には様々なタイプ(doctype)があり、守秘レベル(confidentiality code)
も役割によって分かれる(Role-Based Access Control)。

Audit flowdown

IHE security & privacy toolkit
IHEモデルはアプリケーション間の相互接続を定義。
アプリケーションの動作、機能、ポリシーは定義していない。

•
•
•
•
•
•
•
•
•
•

Audit Trail and Node Authentication (ATNA)
Consistent Time (CT)
Basic Patient Privacy Consents (BPPC)Enterprise User Authentication (EUA)
Cross-Enterprise User Assertion (XUA)
Personnel White Pages (PWP)
Digital Signatures (DSG)
Notification of Document Availability (NAV)
Cross-Enterprise Document Sharing (XDS)
Cross-Enterprise Document sharing via Reliable
messaging (XDR)• Cross-Enterprise Document sharing on Media (XDM)

Local Clinic

・ATNAは説明責任強化の基本。
ユーザ認証とアクセス制御、監査ログ、
NW上の認証。
・信頼されたシステムのみが読める暗号化。
・集中管理が説明責任が容易。

Audit Record Repository
自動/手動での選択
Filtering
Reporting
Alerting
Alarming

136

地域医療連携情報システム構築ハンドブック 201１ 附属書

統合プロファイルとセキュリティ確保

ATNA（監査証跡とノード認証）

説
明
性

認
証

ア 秘
ク 匿
セ
ス

完全 否 個 利
性
認 人 用
拒 情 性
否 報
保
護

直

直

直 直

直

直 直

間

BPPC（患者同意）
CT〔時刻の整合性）

直間

EUA（施設内ユーザ認証）

間

直

間 間

XUA（施設間ユーザ認証）

間

直

間 間

DSG（電子署名）直直直Cookbook: Preparing the IHE Profile Security Section

直
間 間
直

XDS

直

直

間 直

XDR

直

直

間 直

間 直

直

XDM
PWP（職員の台帳）

間直(Risk Management in Healthcare IT Whitepaper)

間 間
直

直

October 10, 2008

間 直
間

Risk assessment and mitigation table

この表を使用して、以下のステップを行う。
①リスクの把握を行い②リスクのimpactとlikelihoodを評価し③高リスクの低減策を取る

Example of level of impact

Guidelines of impact relevance for IHE profiles

Very High

Reputation

Delivery interruption scope

Potential for reduction

May not be able to deliver on mostin SSHA mandateHighcritical requirements

Serious adverse attention from

Major shortfalls in one or more

media, medical establishment

critical requirements

and / or public
MediumMinor adverse attention frommedia, medical establishment

Minor shortfalls in one or more key
requirements

and / or public
Low

Loss of reputation amongclients / partners
Very Low Internal loss of reputation

A few shortfalls in desired

functionality
System should still fully meetmandatory requirements137地域医療連携情報システム構築ハンドブック 201１ 附属書

Example of probability of occurrence

Example of matrix for relevant risks identification

Probability

Likelihood Description

Very HighThis event will probably occur in the near future.

High

This event is likely to occur in the near future.

MediumThis event may occur in the near future.

Low

This event is possible but highly unlikely to occur in the near future.

Very Low

This event is not expected to occur in the near future.

Lebel of impact

Very Low

Low

MediumHigh

Very HighVery low
non relevant risks

Low
MediumHigh

relevant risks

Very high

リスクの低減策
Mandate or suggest grouping of actors with IHE security profiles• ATNA for:
• XUA for conveying of an authentication (against unauthorizedaccess from a user point of view);• DSG for:Template for XDS Affinity Domain
Deployment Planning• CT for sharing of consistent time (against attempt to thwart audit
trails through desynchronization of actors' clocks);• EUA for authentication within an enterprise (against masquerade).
Integrate security features in the profiles
Assign the mitigation of the risk to an identified agent (e.g. productdevelopers, administrative procedures...)

December 2.2008

Contents(2)Contents(1)A.1 はじめにA.2 Glossary
A.3 参考資料
A.4 組織的規約
A.4.1 組織構成
A.4.2 組織的規約
A.4.3 資金提供
A.4.4 透明性
A.4.5 施行と是正
A.4.6 法的問題
法的統治性、義務とリスク配分、免責、発行物への知的財産権
A.5 運用規則
A.5.1 サービスレベルの合意
A.5.2 日常的運営
A.5.3 システム停止の管理
A.5.4 構成管理
A.5.5 新機能要素の追加
A.5.6 データ維持、保存、バックアップ
A.5.7 不具合の回復

A.6 メンバの規約
A.6.1 入会
A.6.2 メンバのタイプ
A.6.3 メンバ方針
A.7 XADの外部からの接続性
A.7.1 相互運用性規約
A.8 システム構造
A.8.1 全体構造
A.8.2 XADのアクタ
A.8.2.1 Business Actors
A.8.2.2 Technical Actor仕様
レジストリ、レポジトリ、ドキュメントソース、ドキュメント利用者、PIX患者IDソース、PIXマネージャ、PIX利用者、
PDQソース、PDQ利用者、 監査リポジトリ

A.8.2.3 XADトランザクション
A.8.2.4 XADトランザクション間のトランザクション

138

地域医療連携情報システム構築ハンドブック 201１ 附属書

Contents(4)Contents(3)A.9 用語と意味
A.9.1 はじめに
識別構成の共通規約
A.9.2 データコンテンツ規約と制限
患者基本情報の制限規程
A.9.3 レジストリのメタデータ
メタデータ識別子、組織名の精密化、組織名要素の仕様、メタデータ属性の精密化、フォルダのメタデータ、
codeListの精密化
A.9.4 サポートする内容
サポートするプロファイル
A.10 患者プライバシと同意
A.10.1 ドキュメントのアクセスと利用の一般則
A.10.2 患者同意
BPPC
A.10.3 プライバシを越える時のガイド

A.11 技術的セキュリティ
A.11.1 認証
役割管理、役割識別、ユーザ・役割の認証、ユーザ・役割の認証管理、証明書権限、委任権限、時間有効性
A.11.2 ノード識別
ノード認証
A.11.3 情報アクセス
監査証跡アクセス、ネットワークのセキュリティ要件、
ノードアクセスのセキュリティ要件、
可搬媒体のセキュリティ、取決めの更新周期

Contents(5)XADにおける機能的役割

A.11.4 情報の完全性
ネットワークの完全性要件、ディジタル署名、
更新と保守方針、訂正方針、更新方針、
アクセス方針、削除方針、フォルダの方針

A.11.5 倫理A.11.6 監査証跡
A.11.7 時刻の一貫性
A.11.8 監査
A.11.9 リスク分析
A.11.10 将来のシステム拡張

Business Actor

Definition

地域のHIE
共有サービスプロバ(State/Provincial, イダ：
Regional, or Local)

Functional Role

説明

ケアの対象

EHRの主たるデータ対象

ケア提供機関の対象

患者、保護者、介護人、法的な代理人

個人的なヘルスケア専門家

患者のGP（かかりつけ医）が近い権利をもつヘルスケア専門家

ケアの対象によって選ばれる

ヘルスケア専門家

患者を直接ケアする場合に部分的に含まれる

ヘルス関連専門家

患者ケア、教育、研究などで間接的に含まれる

行政

患者へのサービス提供を支援するその他の団体

Technical
ActorsActor Optionality

Comments

Business Actor

Definition

Technical
Actors

PIX manager

R/0/C

アクタが条件付きの場合は要求事項を書く

地域のドキュメントリ
ポジトリ

リポジトリサービスをする地域の医療
プロバイダ

XDS-MS:ドキュメントの転 R/0/C
送と共有

ドキュメントレジスト
リを含む

XDS-I

テクニカルアクタの仕様のところに詳細を書く

患者ID相互参照 マ
ネージャ
ポリシーリポジトリ

Actor Optionality

R/0/C

同意リポジトリ

監査リポジトリ

別々のレジストリに登録される場合もある

レジストリ(可能性あり）
PDQ
Supplier

R/0/C

ATNA Audit
Repository

R/0/C

XDS
Registry

R/0/C

XUA Service
Provider

R/0/C

ATNA 監査リ
ポジトリとネッ
R/0/C
トワークセキュリティ

139

Comments

地域医療連携情報システム構築ハンドブック 201１ 附属書Business Actor

Definition

Technical
ActorsActor Optionality

記録を取得するヘルスケア提供者(ドキュメントコンシューマ）

HIEメンバーのリスト（情報取得することが認められている）
を提供

XDS
Document
Consumer

R/0/C

XDS-I
ImagingDocument
Consumer

R/0/C

XDS
Document
Source

R/0/C

XDS-I
ImagingDocument
Source

R/0/C

ATNA
Source Node

R/0/C

PIX
Consumer
PDQ
ConsumerComments

Business Actor

Definition

Technical
ActorsActor Optionality

医療記録を発行するヘルスケア提供者（Document Source)

提供者のリスト(記録の発行が認められている）

XDS
Document
Source

R/0/C

XDS-I
ImagingDocument
Source

R/0/C

ATNA
Secure Node

R/0/C

州の行政機関のリス
XDSト（記録を発行するこDocumentとが認められていSource
る）

R/0/C

XDS-I
ImagingDocument
Source

R/0/C

R/0/C
R/0/C

ATNA
Secure Node

R/0/C

情報を提供する地
域の行政機関（Document Source)

140

Comments

地域医療連携情報システム構築ハンドブック 201１ 附属書K.2 IHE IT Infrastructure Technical Framework｢ITI User Handbook の 1 つで、複数医療機関での連携システム構築時にきめるべき“合意文書”の事項が解説と共に説明されている。
日本においても実際の構築時には参考資料として役立つ内容である。本書は項目とその概要を訳したものである。

IHE IT Infrastructure Technical
Framework
Template for XDS Affinity Domain Deployment Planning
Version 15.0
December 2, 2008

1. はじめに(Introduction)
XAD のコンセプトは ITI TF-1:10 と Appendix K に定義されている。
多くの監視・専門組織にとって、コード化された用語、個人情報保護、文書形式と内容、言語サポート等についての方針が定義されていることが必要である。
本書は、ある地域における独立した XAD、多重の XAD の方針を定義する場合に使われるべき雛形である。実装決定、方針、XDS と関連 Profile の精密化を決めるための一貫した文書形式を示す。
Expected Knowledge and References としては、 XDS、PIX、PDQ、ATNA がある。
さらに、ISO/TS22600-1:2006 Privilege Management and Access Control,
Part1:Overview and Policy management (cross border でのデータ交換におけるシナリオとク
リティカルパラメータを記載)を参照。
2 目標(Goals)
・XAD の構築時に考慮すべき XDS と関連 Profile 領域の定義
・XAD の方針を定義する場合の標準的文書の雛形の提供
2.1 Request for Feedback
2.2 Open Issues and Questions
3 Overview
既存の ITI TF Appendix L にあるチェックリストでは不十分である。
本書が Appendix L に置換る事が提案されている。

141

地域医療連携情報システム構築ハンドブック 201１ 附属書

Appendix A: XDS Affinity Domain Definition Template
本 Template は、単独または複数の XAD において、実装の決定、ポリシー、IHE Profile の精密化の一貫した文書化の雛形を提供する。
さらに、XAD の構築で考慮すべき全関連トピックスのリストと、実装者にとってはポリシーと洗練された決定をガイドする際に役立つことを目指している。
本 Template の全項目が各 XAD において定義されている必要は無い。
A.1 はじめに(Introduction)
XDS Profile に拡張があるならば、ここに記載する。
XAD の拡張が国レベルで定義され、国に公式 IHE 組織があるならば、この組織が拡張を承認るものとし、ここに指定するものとする。拡張機能が承認される前に、テストの必要性を判断するのはこの組織の責任である。
A.2 用語(Glossary)
A.2.1 Terms
Access Control、Accountability
A.2.2 Abbreviations
EHR、HIE、IHE、PER、etc.
A.3 参考資料(Reference Documents)
XAD拡張での参照ドキュメント、拡張の意味を示すドキュメントのリスト。
A.4 組織的規約(Organizational Rules)
XAD 組織構造を定義する。
資金提供者、管理者と運営者の一覧、各役割と責任を明確に定義し、契約文書にすべきである。XAD への加入希望者が、加入情報を得たり XAD にアクセスしたりするために接触をすべき
対象を明確にすべきである。
A.4.1 Organizational Structure
A.4.2 組織構成(Organizational Roles)
XAD の実装に関して経済的考慮事項を説明するものとする。
資金(公的/私的、税、など)、ビジネスモデル、運用と補修の会計計画を含む。
A.4.3 資金(Funding)
A.4.3.1 Fee Structure
A.4.3.2 Re-Imbursement Policies
A.4.3.3 Insurance Policies
A.4.3.4 Fiscal plan for System Operation, Maintenance, and Innovation
A.4.4 透明性(Transparency)
正確でタイムリな情報開示の方法が文書化されるものとする。
A.4.5 施行と是正(Enforcement and Remedies)
XADに関する施行規約(支払い、アクセス権限、パフォーマンスの要求、セキュリティ
等)の責任組織の在り処を明確にする。
A.4.6 法的問題(Legal Issues)
A.4.6.1 法的統治性(Legal Governance)
ユーザ、出版者、IT スタッフ、ベンダに関係する法的事項の管理に関する方針の定義。
A.4.6.2 Government Regulations
A.4.6.3 義務とリスク配分(Liability and Risk Allocation)
A.4.6.4 免責(Indemnification)
XDS の実装に関する免責事項を記載する。本項に書くべき事項のガイドとして、以下の例がある。
・利用者によるデータ誤使用への法的告訴に対しての、提供者の免責・患者からデータ誤利用に対しての告訴時、賠償責任を回避する仕組み

142

地域医療連携情報システム構築ハンドブック 201１ 附属書・データ提供者と全利用者間の免責の取決め
・データ使用以上に、公表についての問題を話す方法
A.4.6.5 発行物への知的財産権(Intellectual Property Rights to Published Documents)
A.5 運用規則(Operational Rules)
A.5.1 サービスレベルの合意(Service Level Agreements)
A.5.2 日常的運営(Daily Governance)
XDS の運営レベルでの管理方法を記載する。
A.5.2.1 Policy Governance
A.5.2.2 Policy Change Procedures
A.5.2.3 Publication and Notification Policies
A.5.2.4 システム停止の管理(Management When Systems are Unavailable)
XAD の各構成要素が使用不可である場合の管理方針を定義する。例えば、PIX が利用できない場合、予定されたダウンタイムの通知方法、予定外のシステムダウンの原因と解決の通知、など。
A.5.3 構成管理(Configuration Management)
H/W や S/W の機能更新、構成変更等の管理方法を定義する。他要素への影響(停止をもたらすかもしれない、機能や構成の変更を必要とする)要素を変更するために必要な承認は何かを説明する。X.10 を参照する。
A.5.4 新機能要素の追加(Addition of New Components)
XAD への新要素の追加手続きを定義する。XAD の新要素追加の方法。新要素の認可をする
組織は何処かを説明する。
Repository の追加、他 Repository への統合、XDS-I のローカルと集中アーカイバ間の移行。
A.5.5 データ維持、保存、バックアップ(Data Retention, Archive, and Backup)
監査証跡の扱いと保持期間
A.5.6 不具合の回復(Disaster Recovery)
A.6 メンバの規約(Membership Rules)
A.6.1 入会(Acceptance)
XAD のメンバに加わり、構成要素とデータにアクセスできる組織、個人のタイプを定義する。
A.6.2 メンバのタイプ(Types of Membership)
公表データへのアクセス可能性 (例、読取のみ、発表のみ、等) を定義するメンバ資格タイプの有無。
A.6.3 メンバ方針(Membership Policies)
メンバの状況を管理する規約を定義する。
A.7 XAD の外部からの接続性(Connectivity To the XDS Affinity Domain from External Systems)
A.7.1 相互運用性規約(Interoperability Strategy)
ドメイン境界を越えたデータアクセス方法の手順が規定されるものとする。
A.7.1.1 External Connectivity Through Portals
A.8 システム構造(System Architecture)
情報の訂正と公表の安全性のために、AP のシステム構造が全参加者によって特定され理解されていなければならない。ポリシー合意文書は、種々の Actor/Profile をサポートするシステムの構造、文書タイプと公表方針に関しての詳細を含むものとする。
A.8.1 全体構造(Global Architecture)
利害関係者、システム機能要素を含む全体のダイアグラムが記載されるべきである。XDS-I のImage データの置き場(ローカルか地域アーカイバか)。
A.8.2 XAD のアクタ(Affinity Domain Actors)
XAD Integration Profile で定義される IHE アクタの実装に当たっては、システム通信上で特定できる必要がある。

143

地域医療連携情報システム構築ハンドブック 201１ 附属書A.8.2.1 Business Actors
A.8.2.2 Technical Actor Specifications
A.8.2.2.1 XDS ドキュメントレジストリ(XDS Document Registry)
A.8.2.2.2 XDS ドキュメントリポジトリ(XDS Document Repository)
A.8.2.2.3 XDS ドキュメントソース(XDS Document Source)
A.8.2.2.4 XDS-I ドキュメントソース(XDS-I Imaging Document Source)
A.8.2.2.5 XDS ドキュメント利用者(XDS Document Consumer)
A.8.2.2.6 XDS-I ドキュメント利用者(XDS-I Imaging Document Consumer)
A.8.2.2.7 XDS Patient Identity Source
A.8.2.2.8 PIX 患者 ID ソース(PIX Patient Identity Source)
A.8.2.2.9 PIX マネージャ(PIX Manager)
A.8.2.2.10 PIX 利用者(PIX Consumer)
A.8.2.2.11 PDQ Patient Demographics Supplier
A.8.2.2.12 PDQ Patient Demographics Consumer
A.8.2.2.13 ATNA Audit Record Repository
A.8.2.2.14 ATNA Secure NodeA.8.2.2.15 Secure Application
A.8.2.2.16 CT Time Server
A.8.2.2.17 CT Time Client
A.8.2.2.18 Any Additional IHE Actor Systems
A.8.2.2.19 Additional Affinity Domain Specific Recognized Technical Actors
A.8.2.3 XAD トランザクション(XDS Affinity Domain Transaction Diagram)
XAD の通信ダイアグラムを定義する。特に、XAD 拡張では必須として定義している付加的通信の詳細は重要である。
A.8.2.4 XAD 間のトランザクション(Cross XDS Affinity Domain Transaction Support)
この XAD には属さない外部システムへの通信に必要な詳細を規定する。
“異なる code sets”、さらに” ID 認証の妥当性”を扱う手続きを説明する。
A.9 用語と意味(Terminology and Content)
A.9.1 はじめに(Introduction)
XAD で精密化される用語と内容の基本部分を説明する。
A.9.1.1 識別構成の共通規約(Common Rules for Identifier Construction (example))
例えば、OID の生成規約を指定する。
OID:ISO オブジェクト識別子で、64 字以内の数字とピリオッド。
A.9.2 Data Content Rules and Restrictions
A.9.2.1 Example of Rules and Restrictions for Patient Demographic Data
A.9.3 レジストリのメタデータ(XDS Registry Metadata)
A.9.3.1 XDS Document Entry Metadata
ITI TF-2: Table 4.15 にある Document Metadata Attribute Definitions の定義をする。
A.9.3.1.1 作成組織名の精密化(Refinement of author Institution (example))
XON:HL7 V2 Organization Name の第一コンポーネントで指定する組織名。
A.9.3.1.1.1 組織名要素の精密化(Refinement of Organization Name component (example) )A.9.3.1.1.2 その他(Etc.)
A.9.3.1.2 ドキュメントエントリ属性の精密化(Refinement of Further XDS Document Entry Attributes (example))
A.9.3.2 XDS Submission Set Metadata
ITI TF-2: Table 4.1-6 Submission Set Metadata Attribute Definitions の定義をする。
A.9.3.2.1 Refinement of Submission Set Metadata Attributes (example)
A.9.3.3 フォルダのメタデータ(Folder Metadata)
ITI TF-2: Table 3.14.4.1-7 Folder Metadata Attribute Definitions の定義をする。

144

地域医療連携情報システム構築ハンドブック 201１ 附属書A.9.3.3.1 codeList の精密化(Refinement of codeList (example)
A.9.4 サポートする内容(Supported Content)
A.9.4.1 サポートするプロファイル(Supported Content Profiles)
XDS-MS,XDS-SD,XDS-I,XDS-BPPC,XDS-*,等
A.9.4.1.1 XDS-MS Document Content Refinement (Example)
A.10 プライバシ(Patient Privacy and Consent)
A.10.1 ドキュメントのアクセスと利用の一般則(General Guidelines Regarding Document Access and Use)
XAD の情報へのアクセスと利用に関する一般側を定義する。BPPC の Privacy Access Policy
では、いくつかの例を示している。
アクセス権限が利用者の役割に結びついているならば、アクセスが許される
ドキュメント種別に対する利用者の役割を規定するアクセス制御マトリックスが決められるべきである。
A.10.2 患者同意(Patient consent)
A.10.2.1 BPPC
BPPC Profile のサポートをしなければならないか否かを決める。BPPC 利用のルールを定義する。
A.10.3 プライバシを越える時のガイド(Privacy Over-ride Guidelines)
緊急時、グレークグラス、システム停止、等の条件を特定する。
A.11 技術的セキュリティ(Technical Security)
各ドメインでは独自のセキュリティルールを用いがちであるが、同一のセキュリティモデルを使うことが望ましい。CEN、ISO で定義された security standard が最初のゴールである。
A.11.1 認証(Authorization)
A.11.1.1 役割管理(Role Management)
A.11.1.1.1 Functional Roles
A.11.1.1.2 Structural Roles
A.11.1.2 役割識別(Authentication of Users/Role)
パスワード規約、2要素、認証、等の識別方法。
A.11.1.2.1 ユーザ・役割の認証管理(User/Role Certificates management)
A.11.1.3 証明書権限(Attestation rights)
A.11.1.4 委任権限(Delegation rights)
A.11.1.5 時間有効性(Validity time)
認証等の有効な時間を決めなければならない。
A.11.2 ノード識別(Node Authentication)
A.11.2.1 ノード認証(Node Certificates Management)
A.11.3 情報アクセス(Information Access)A.11.3.1 監査証跡アクセス(Security Audit Log Access)A.11.3.2 ネットワークのセキュリティ要件(Network Communication Access Security Requirements)
XADでのネットワークアクセスのセキュリティ要件を特定する。
A.11.3.3 ノードアクセスのセキュリティ要件(Node Access Security Requirements)
例えば、全ノードがATNA Profileに従う必要が有るか否か。
A.11.3.4 可搬媒体のセキュリティ要件(Removable Media Access Security Requirements)
A.11.3.5 取決めの更新周期(Agreement validity period)
取決め内容の有効期限は、その取決め内で規定するものとする。
A.11.4 情報の完全性(Information Integrity)
X.10.4.1 ネットワークの完全性要件(Network Communication Integrity Requirements)
完全性チェックに使われる方法。
A.11.4.2 ディジタル署名

145

地域医療連携情報システム構築ハンドブック 201１ 附属書(Document Digital Signature Requirements/Policy)
A.11.4.3 更新と保守方針（Document Update and Maintenance Policies)
A.11.4.3.1 訂正方針(Document Correction Policy)
A.11.4.3.2 更新方針(Document Update Policy)
A.11.4.3.3 アクセス方針(Document Read Policy)
A.11.4.3.4 削除方針(Document Deletion Policy)
A.11.4.4 フォルダの方針(Folder Update and Maintenance Policies)
A.11.4.4.1 Folder Correction Policy
A.11.4.4.2 Folder Update Policy
A.11.4.4.3 Folder Read Policy
A.11.4.4.4 Folder Deletion Policy
A.11.5 倫理(Ethics)
規則と規制だけでは全ての状況をカバーできない。それ故に、倫理が考慮され、全員が共同する責任の枠組に関して全員によく理解してもらうための覚書が公式化されるべきである。
A.11.6 監査証跡(Secure Audit Trail)
全 transaction は ATNA Profile を使ってログされるものとする。旧来のシステムが ATNA を備
えていなければ、サポートの仕方を定義するものとする。
A.11.7 (Consistent Time)CT Profile のサポート方法を規定する。
A.11.8 監査(Audit check)
何時、誰が監査し、適切な行動が取られるかが合意されるものとする。
A.11.9 リスク分析(Risk analysis)
尐なくとも、年 1 度は見直すものとする。
A.11.9.1 General Mitigations
A.11.9.1.1 Common Criteria (ISO/IEC 15408)
A.11.9.2 Identified Risks
A.11.10 将来のシステム拡張(Future system developments)

146

地域医療連携情報システム構築ハンドブック 201１ 附属書

附属書 L.

提案依頼事項について

本附属書では、システム発注時に考慮するべき、提案依頼事項について述べる。地域
医療連携情報システムに限らず、製品導入の際には開発企業が信頼できるかを確認することが重要である。
主に下記については、仕様書に提出を明記して、技術審査に用いる。
・ 品質管理体制
 開発業者の製品に対する品質管理体制の説明資料
・ 開発体制および開発実績
 製品開発に関わる者の過去の開発実績に関する説明資料
・ 技術者スキル 情報工学、医療情報などに関する保有資格
 プログラム開発に従事した年数
 使用できるコンピュータ言語・ 個人情報保護方針および情報セキュリティ管理体制
 開発業者の情報セキュリティ管理体制に関する説明資料
 開発業者の個人情報保護方針に関する説明資料
・ 保守体制 電話対応可能時間
 夜間・休日の対応
 定期点検方法
製品を長期的に維持・管理するために、開発企業に開発体制や技術者のスキル、品
質維持の仕組み、保守体制などを説明する資料を提出させる必要がある。
技術者のスキルには、情報処理技術や医療情報、医療に関して取得している資格や製品開発に携わっている年数を説明させる。

147

地域医療連携情報システム構築ハンドブック 201１ 附属書

本ハンドブックは、厚生労働省事業により支援を受けて作成しました。
転載及び引用については出典を明確にしてください。
例示、サンプルについての使用は自由です。
本書の内容を利用した実装に関する責任は使用者にあるものとします。

2011 年 12 月 20 日発行「地域医療連携情報システム構築ハンドブック 2011」
附属書―IHE XDS による HIE（Health Information Exchange）の構築―
著作権、発行元： 日本 PACS 研究会・日本 IHE 協会

148