「地域医療連携情報システム構築ハンドブック 2011」
別冊
IHE-XDS をめぐる最近の動向――日米の政策、クラウド技術、広域な連携について――

2011 年 7 月

ePHDS 委員会/日本 PACS 研究会
日本 IHE 協会編

目次
第１章 我が国の新情報通信戦略構想と IHE との関わり ..................................... 5
１．１ はじめに ........................................................................................... 5
１．２ 新戦略構想 ...................................................................................... 5
１．３ 新戦略構想として考えられるシステム .................................................... 6
１．３．１ システム機能 ............................................................................. 8
１．３．２ システム設計上の課題 ................................................................ 8
１．４ 構想に利用が考えられる ITI 統合プロファイル ....................................... 9
１．５ 利用が考えられる ITI 統合プロファイルの簡単な説明............................. 10
１．６ おわりに .......................................................................................... 11
第２章 米国での最新の NHIN 構想 ................................................................ 13
２．１ 背景 ............................................................................................... 13
２．２ NHIN 構想及び動向 ......................................................................... 13
２．３ NHIN CONNECT.............................................................................. 16
２．４ NHIN Direct ..................................................................................... 18
２．５ NHIN 仕様の概要 ............................................................................. 21
２．６ 「有意義な利用」について .................................................................. 24
２．７ 世界の動向との関係 ......................................................................... 26
第３章 NIST のクラウド定義とクラウドの現状 ..................................................... 29
３．１ クラウドの定義 .................................................................................. 29
３．２ IHE-XDS の一般的事例 .................................................................... 31
３．３ クラウド環境での院内電子カルテと IHE-XDS による地域医療連携 ........... 33
３．４ クラウドの ISMS 対応による国際標準化と個人情報保護・情報セキュリティ .. 36
３．５ ISMS 標準化の活動とクラウド .............................................................. 36
３．６ クラウド利用の保健医療機関における「ISMS の実践」 ............................. 37
第４章 クラウドガイドラインと IHE .................................................................... 40
４．１ はじめに .......................................................................................... 40
４．２ 本ガイドラインと IHE の関連 ............................................................... 44
４．３ 既存のガイドラインとの関係 ................................................................ 44
４．３．１ 通信上の管理策 ....................................................................... 45
４．３．２ 情報の管理責任 ....................................................................... 45
４．３．３ データの所在管理 ..................................................................... 45
４．３．４ 法的責任 ................................................................................. 46
第５章 最新の IHE ソリューションによる広域の連携システムの構築可能性について48
５．１ はじめに .......................................................................................... 48
５．２ Cross Community Access の概要 ........................................................ 48
５．３ コミュニティ間の画像情報連携 （XCA-I） ............................................. 50
５．４ PHR への展開 .................................................................................. 51
５．５ ガイドラインとコミュニティ間連携 .......................................................... 52

第６章 直接医療機関をつなぐ安全な連携についての IHE 統合プロファイル ........ 54
６．１ Point-to-Point の地域連携の必要性・誕生の背景 ................................. 54
６．２ IHE が提案する XDR"Cross-Enterprise Document Reliable Interchange"概要............................................................................................................... 54
６．３ 事例紹介：放射線医学総合研究所が必要とする施設間連携機能のユースケ
ース......................................................................................................... 57
６．４ 導入事例：粒子線治療の多施設共同研究症例情報収集システム ............ 58

執筆者一覧

・第 1 章喜多 紘一

保健医療福祉情報安全管理適合性評価協会(HISPRO)・第 2 章大林 正晴

株式会社

・第 3 章森口 修逸

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

・第 4 章野津 勤

理工学振興会・第 5 章細羽 実

京都医療科学大学

・第 6 章向井まさみ

放射線医学総合研究所

管理工学研究所

重粒子医科学センター医療情報室

本ハンドブック（別冊）の一部は、平成 22 年度、日本 IHE 協会の事業の一環として、厚生労働省の補助を受けて作成されたものである。

はじめに
JPACS 研究会の ePHDS 委員会と IHE 協会 ITI 委員会 XDS-WG の合同委員会は、IHEによる医療連携情報システム構築についての検討を進めて来ました。2010 年度には
連携システムの実現が、我が国の状況、クラウドの展開、各省のガイドラインの制定の中で、どのように実施可能であるかについて検討を行いました。
本別冊では、その補足資料として、日米の最近の政策を踏まえ、医療機関間の連携、患者を含めた連携、さらに連携システムを含む広域の連携体制などの在り方、それらを実現するための IHE 統合プロファイル、医療連携クラウド実現の可能性、それを規定するガイドラインについての問題点を抽出し、解説することとしました。最後に連携の出発点ともいえる直接医療機関をつなぐ安全な連携についての IHE 統合プロファイルについて、具体的な例をもとに解説しました。
第１章 我が国の新情報通信戦略構想と IHE との関わり
第２章 米国での最新の NHIN 構想
第３章 NIST のクラウド定義とクラウドの現状
第４章 クラウドを医療連携システムとして利用する場合のガイドラインのとらえ方
第５章 最新の IHE ソリューションによる広域の連携システムの構築可能性について
第６章 直接医療機関をつなぐ安全な連携についての IHE 統合プロファイル
本委員会では、以上の検討結果を踏まえ、継続して問題点を抽出し、地域医療連携
情報システム構築のためのソリューションづくりを進めていきたいと考えています。

4

第１章

我が国の新情報通信戦略構想と IHE との関わり

１．１ はじめに
新情報通信戦略構想でネットワークを利用した医療情報サービスとして「どこでも MY病院構想」および「シームレスな地域連携医療」構想が取り上げられている。一方、IHEの 活 動 は 、 Cardiology 、 Eye Care 、 IT Infrastructure 、 Laboratory 、 Patient Care
Coordination、Patient Care Devices、Quality, Research and Public Health、Radiation
Oncology、Radiology のドメインに分かれ、それぞれで統合プロファイルの作成がなされている[1]。
ここではネットワーク構想に深く関連する IT Infrastructure ドメインの統合プロファイ
ルで新戦略構想に利用可能なものを主に取り上げて概要を説明し、その現状と課題をまとめた。
１．２ 新戦略構想
ＩＴ戦略本部（高度情報通信ネットワーク社会推進戦略本部）が平成 22 年 5 月 11 日に発行した「新たな情報通信技術戦略」（新戦略構想） [2]によると「国民本位の電子行政の実現」、「地域の絆の再生」および「新市場の創出と国際展開」が挙げられている。さ
らに、その中の「地域の絆の再生」の中で「医療分野の取組」として重点施策が取り上げられている。以下引用する。
「全国どこでも過去の診療情報に基づいた医療を受けられるとともに、個人が健康管理に取り組める環境を実現するため、国民が自らの医療・健康情報を電子的に管理・活用するための全国レベルの情報提供サービスを創出する。このため、第一段階として、個人が自らに対する調剤情報等を電子的に管理する仕組みを実現する。また、匿名化されたレセプト情報等を一元的なデータベースとして集約し、広く医療の標準化・効率化及びサービスの向上に活用可能とする仕組みを構築する。」
具体的施策として、
１）「どこでもＭＹ病院」構想の実現
２）シームレスな地域連携医療の実現
３）レセプト情報等の活用による医療の効率化
４）医療情報データベースの活用による医薬品等安全対策の推進「「どこでもＭＹ病院」構想の実現」とは、「全国どこでも自らの医療・健康情報を電子的に管理・活用することを可能にする「どこでもＭＹ病院」構想を実現することとし、遅くとも 2013 年までにその一部サービス（調剤情報管理等）を開始する。このため、2010 年度中に、診療明細書及び調剤情報の電5子化方策や、「どこでもＭＹ病院」構想を実現する上での運営主体、診療情報・健康情
報等の帰属・取扱い等について結論を得る。また、本構想の実現に当たり、救急医療体制の強化にも資するよう検討する。」となっている。
また、「シームレスな地域連携医療の実現」は、「遅くとも 2015 年までに地域医療支援病院を中心とし、生活習慣病などを対象として、
情報通信技術を活用した地域連携クリティカルパスや医療から介護まで健康に関わる施設間でのシームレスなデータ共用を可能にする体制を各地に構築するため、2010
年度中に、具体的な方針を固める。また、医療情報システム等の普及と標準化の推進を行うとともに、死因究明に精通した医師が尐ない中で、地域連携により死亡時画像
診断（Ａｉ）による死因究明を推進する。
さらに、医師不足地域等における患者の利便性を向上させるため、処方せんの電送交付をはじめ、遠隔医療の実施可能範囲の明確化及び遠隔医療に対する診療報酬
等の適切な活用など、遠隔医療の普及方策を検討する。」となっている。これに従い行
程表も作成され[3]、これに基づいて、経済産業省から公募事業「医療情報化促進事業」が始まっている。
この事業は「どこでも MY 病院構想の実現に向けた実証事業」、「シームレスな地域
連携医療の実現に向けた実証事業」および「共通項目の開発に向けた実証事業」の３つの実証テーマを公募し実施している[4]。
なお、この事業の共通基盤については、「経済産業省の平成 22 年度サービス産業
活動環境整備調査事業（医療等情報化共通基盤構築調査事業）」が実施され、その報告書が公表されている[5]。
１．３ 新戦略構想として考えられるシステム「どこでも MY 病院構想」は、医療機関等に存在する個人の医療・健康情報を直接活用するのではなく、一度個人に提供された情報を活用するサービスである。本サービスを使うことで初診の場合でも、かかりつけ医に準じた診療履歴に基づいた診療を受けることができる。情報は蓄積により価値が増大することを前提としている。
「シームレスな地域連携医療構想」は、在宅医療と介護の情報連携、疾病管理における情報連携、二次医療圏を超えた地域
医療情報連携の促進を目指している。これらの実現によって、「医療・介護の質の向上」、「地域の患者の生活習慣病等の重症化防止」および、「効率的な医療情報連携」の促進を期待している。

6

また実証事業では、
１） どこでも MY 病院構想の実現に向けた実証事業
自らの医療・健康情報を電子的に管理・活用するモデル事業を実施し、運営主体のあり方の検討、個人の医療・健康情報を扱うための適切なセキュリティについて等「MY 病院構想」を実現する上で必要とされる項目について実証事業
２）シームレスな地域連携医療の実現に向けた実証事業
生活習慣病などの疾病管理を目的として IT 技術を活用し、医療機関間を中心とした一定の地域の関係者間において、シームレスにデータ共用を可能にするモデル構築の実証事業。
となっている。
こうした条件をふまえてＭＹ病院とシームレス事業を包括するようなシステムを考えると図 1－1 のようになる。

MY病院・シームレス連携ネットワークシステム
シームレス連携システム
４疾病５事業
等クリティカ
ルパス＆症
例データ
ベース

専
門
医

かか
りつ
け医

MY病院システム

４疾病５事業等診療用連
携データベー
ス

一般医師
等診療ス
タッフ

薬
局

個人健康情
報保存デー
タベース

スポー
ツセンタ

支援者・
NPO等

コンセ
ルジュ

支援情報システム

本人

図１－１ ＭＹ病院・シームレス構想を統合したシステム

7

家族
等

１．３．１システム機能１）シームレス連携システム
・4 疾患 5 事業等診療用連携データベース
・クリティカルパスに沿って医療機関間での患者情報の共有化
・簡易な入力システムの活用
・4 疾患 5 事業等クリティカルパス＆症例データベース
４疾患 5 事業等のクリティカルパスや診断データ、画像データ等の症例の効率的保存と解析を相互共有可能とする。
２）ＭＹ病院システム①個人健康情報保存データベース
治療サマリ、健康維持計画指導書、検査データ、調剤情報、健診データ、日常データ等の保存・閲覧・個人アカウントにより管理
・入力サービス⇒紙ベースの診療情報をデジタイズ⇒オフライン標準フォーマットのデジタル情報を入力
・出力サービス⇒フォロー事項の郵送、患者紹介、セカンド・オピニオン等へ提供する情報出力②支援情報システム
患者団体、ＮＰＯ、コンセルジュ、家族等が日常支援する為に必要なデータ、支援状況の入力、健診・検査・トレーニング予約状況等
１．３．２ システム設計上の課題
１）シームレス連携システム
・4 疾患 5 事業等クリティカルパス＆症例データベースに保存する情報の種類と粒度
・4 疾患 5 事業等診療用連携データベースに保存する情報の種類と粒度
・情報共有の為の情報によるアクセス権の設定と同意・症例データベースの利活用時の個人情報保護
２）ＭＹ病院システム
・長期支援に必要な情報と粒度・検索用メタデータ（キー情報）の検討
・長期支援計画の検討
・情報の入力方法、表示方法
・他業種、家族間のデータ共有のあり方とアクセス制御技術・同意取得内容と方法
8

・コンセルジュ機能の内容
３）共通な課題
・ビジネスモデルの確立
・施設間連携情報および長期保存情報管理の為のＩＤ管理
・情報提供の範囲とアクセス制御（家族・支援者間の共有と機密性へ配慮）
・適切な価格・機能・安全性を持つ共有ネットワーク(ASP・SaaS・クラウドの評価)・システムの新規標準化提案と既存標準化への対応
・長期データの互換性・真正性・見読性・保存性・相互運用性・ポータビリティ確保と必
要な粒度
・シームレス連携システムとＭＹ病院システム間の情報交換の運用
・シームレス連携システムとＭＹ病院システムに蓄積された情報の第三者利活用・連携する場合の責任分界点の考え方
１．４ 構想に利用が考えられる ITI 統合プロファイル
こうした、構想で採用あるいは参考にすべきＩＨＥ ＩＴＩの統合プロファイルとしては以下のものが挙げられる。
最終版（Final Text – stable）として発行されたものでは[ATNA] Audit Trail and Node Authentication ,[BPPC] Basic Patient Privacy Consents,[XDM] Cross-enterprise Document Media Interchange,[XDR] Cross-enterprise Document Reliable Interchange,[XDS] Cross Enterprise Document Sharing,[XDS-SD] Cross-enterprise Sharing of Scanned Documents,[XUA] Cross-Enterprise User Assertion,[EUA] Enterprise User Authentication,[PDQ] Patient Demographics Query,[PIX] Patient Identifier Cross Referencing[RＩD] Retrieve Information for Displayがあり、施行実証中のものとしては[XCA] Cross-Community Access,[RFD] Retrieve Form for Data Capture[HPD] Healthcare Provider Directoryがある。
9具体的には、「どこでも MY 病院構想の実現に向けた実証事業」では[XDM]、[XDR], [XDS-SD]および [RFD]が有効である。
また、「シームレスな地域連携医療の実現に向けた実証事業」では、上記に加え[XDS]、[PIX] [PDQ] [BPPC] [XCA] [ATNA][HPD]および症例データベースへの応用として[RFD]が有効である。
さらに、ＸＤＳのレポジトリからレジストリに送られるトランザクションに含まれるメタデー
タは各構想のレジストリを作成する場合の参考となる。
１．５ 利用が考えられる ITI 統合プロファイルの簡単な説明
以下、各プロフィルを簡単に説明する。
[PIX]：複数の患者 ID ドメイン間において、患者 ID 相互参照を可能にする。これらの患者 ID は、ID 利用システムで活用され、これにより、特定の患者について、異なる ID を利用しているソースからの患者情報を関連付けさせることができる。
[PDQ]：複数の分散されたアプリケーションが、集中管理された患者情報サーバに対し、ユーザが指定する検索基準に基づくクエリを実施し、患者の基本情報を直接取り込む
ことができる方法を提供する。
[XDS]：ケアコミュニティなど、医療連合ドメイン（Clinical Affinity Domain）に属するヘル
スケア提供機関が診療記録を文書の形で共有し、患者ケアにおいて協力することを可能にする。
[EUA]：1 人のユーザ当たり 1 つの名前を確立する手段であって、この統合プロファイルに参加する装置およびソフトウェアのすべての上で使用できる。
[ATNA]：ノードのために仮定されたセキュリティ環境(ユーザ識別、認証、認可、アクセ
ス管理、など)について記述、あるいはノード用の基礎的な監査要求事項を定義等を行い、基礎的な安全ノードの特性を確立する。
[BPPC]：患者プライバシー同意を記録するメカニズムで、公表を認可するために使用された患者プライバシー同意を得て XDS に公表された文書にマークする方法およびXDS 利用者が使用に適するプライバシー同意を強化するため使用する方法を提供する。
[XDS-SD]：紙、フィルムや非標準の電子データにメタデータをつけて管理する方法を提供する。
[XDM]：CD,USB メモリーや e メールの添付文書で文書とメタデータを送ることができる。
[XDR]：信頼できる 1 対１のプッシュ型ネットワークで施設間の情報交換を行う仕組みを提供する。
[XCA]：他のコミュニティで得られた患者関連のデータを要求して得られる為の仕組み
10

を提供する。
[RFD]：治験や公衆衛生の調査フォームに直接ＥＨＲから直接転記する仕組みを提供する。
[RＩD]：単純なブラウザーベースの読み取り専用の為に診療情報へのアクセスする仕組
みを提供する。
[HPD]:ヘルスサービス提供者および施設の属性を提供する仕組み
１．６ おわりにここではＩＴＩ統合プロファイルを中心に説明したが、その他、以下のプロファイルがある。
Cardiology ドメインでは、[DRPT] - Displayable Reports
ＰＣＣ（Patient Care Coordination）のドメインも注目に値するプロファイルがある。
[MS]: Medical Summaries、[XPHR]: Exchange of Personal Health Record Content、[PPHP]: Pre-procedural History and Physical、[FSA]： Functional Status Assessments、[EDER]: Emergency Department Encounter Record[EDR]: Emergency Department Referral、[QED]: Query for Existing Data
等のサマリやレポート関連である。
Radiology ドメインでは、Portable Data for Imaging (PDI)
Cross-enterprise Document Sharing for Imaging (XDS-I)があり、Laboratory ドメインでも、[XD-LAB] - Sharing Laboratory Reportsがある。
日本ではＸＤＳ関連が中心に検討され、ハンドブックが作成された。ＪＰＡＣＳ研究会のホームページに「地域医療連携情報システム構築 ハンドブック 2010」として載せられている [6]。まだＸＤＳは構築経験のあるベンダが尐ない。積極的にハンドブック等で習11

得していただいて、標準的な実装により情報共有が進められ適切な医療環境が構築されることを期待したい。
それ以外のプロファイルは、ＰＤＩが取り上げられているが、それ以外にも注目すべきものも多々あり、新戦略に沿ったインフラの構築を進めるにあたっても検討に値すると思われる。今後とも、分担してフォローおよび普及活動を続け、具体例を積み重ねて普及をはかるべきである。
[参考文献][1] IHE Domain: http://www.ihe.net/Domains/index.cfm[2] ＩＴ戦略本部：新たな情報通信技術戦略、平成 22 年 5 月１１日
http://www.kantei.go.jp/jp/singi/it2/100511honbun.pdf[3] ＩＴ戦略本部：新たな情報通信技術戦略 工程表、平成 22 年 6 月 22 日
http://www.kantei.go.jp/jp/singi/it2/100622.pdf[4] 経済産業省：平成 22 年度「医療情報化促進事業」を実施する事業者に係る企画競争（委託先の公募）について、平成 23 年 1 月 26 日
http://www.meti.go.jp/information/data/c110126aj.html[5] 経済産業省：「平成 22 年度サービス産業活動環境整備調査事業（医療等情報化
共通基盤構築調査事業）」、平成 23 年 2 月 27 日
http://www.kthree.co.jp/press/news_iryojoho.html[6] ePHDS 委員会/日本 PACS 研究会 & 日本 IHE 協会 編:地域医療連携情報シス
テム構築 ハンドブック 2010―IHE XDS による HIE（Health Information Exchange）の構
築― 2010 年 3 月
http://www.jpacs.jp/book2010.pdf

12

第２章

米国での最新の NHIN 構想

２．１ 背景NHIN(National Health Information Network) は、米国の国家医療情報ネットワークである。NHIN は、2002 年に開始された NHII (National Health Information Infrastructure「国家医療情報基盤プロジェクト」)を引き継いで 2005 年に開始された。その後、2009 年に成立した ARRA (American Recovery and Reinvestment Act「米国再生・再投資法」)の中で HITECH (Health Information Technology for Economic and Clinical Health Act「経済および医療のための医療情報技術に関する法律」) 法として、医療に特有の条項が加えられている。
この ARRA では、さまざまな業界に対して約 7870 億 US ドルの資金を投じることを規定しており、そのうち HITECH 関連には、約 190 億 US ドルが割り当てられている。
190 億 US ドルのうち、開業医に対して割り当てているのはわずか数万ドルであるのに対し、メディケア (高齢者向け医療保険制度) およびメディケイド (低所得者向け医療費補助制度)を受け入れて、EMR (Electronic Medical Record「電子医療記録システム」)を導入して使用する病院やマルチホスピタル・システムに対しては、数千万ドルもの資金を割り当てている。
この法案によって提供される資金は、診療所や病院に直接支払われるのではなく、
HITECH で定義された法規制を満たす診療所、病院に対し、メディケアおよびメディ
ケイドの還付金を増やすという形で配分される。
ONC (Office of the National Coordinator for Healthcare IT「国家医療 IT 調整官室」)
は、HHS (Department of Health and Human Services「保健福祉省」)の一部門であり、NHIN を管轄する米国連邦政府の主要な行政機関である。NHIN 標準の仕様の策定
は、米国商務省の NIST (National Institute of Standards and Technology「国立標準技術研究所」)と調整を図りながら推進されている。
２．２ NHIN 構想及び動向
NHIN 構想は、医療機関や関連団体、個人がインターネットを介して医療情報を安全に共有するためのシステム、及びそのために必要な基盤の構築を目指すもので、本格的な導入に向け、個人によるデータへのアクセス、プライバシーやセキュリティの監査などの機能の整備が進められている。
なお、NHIN 構想は ONC が主導して実施されているが、民間側も IBM、Northrop
Grumman、Accenture、Computer Sciences Corp が、それぞれ４つのコンソーシアムを組織して、ビジネスモデルやプロトタイプの開発を進めている。
また、2010 年 8 月、NHIN の実証に向け、ONC は Lockheed Martin 社と 2 年間で 900万ドルの委託契約を締結した。同社は、この契約の中で、NHIN の技術と標準、および
13

健康情報の安全な送受信に必要なコンポーネントの試験を行うための実証 Web サイトを設立することとなっている。
また、VA（Veterans Affairs「退役軍人局」）も同月末、インディアナ州での医療 IT パ
イロットプログラム（Indiana Health Information Exchange）の実施を発表しており、同プ
ログラムでは、病院や VA の医療施設を含む 60 ヶ所の施設と患者 600 万人による健康情報の共有が行なわれる。
さらに、HHS は 2010 年 9 月、地方の病院に対して医療・健康情報の電子化の促進に向けた技術支援費用として、新たに 2,000 万ドルの助成金を設定すると発表した。同
費用は ARRA を通じて拠出されるもので、41 州およびワシントン DC、ネイティブ・アメリ
カン居住区における地方病院、および優先すべき機関として特定された医療機関
1,655 ヶ所を対象としている。
（NHIN の挑戦）
NHIN は、インターネットで医療データを交換できるようにするための枠組みである。しかし、 NHIN は確立されたものではなく、医療データの交換に必ず必要な枠組みというわけでもない。医療データの交換は、そう簡単に実現されるものではなく、すぐにでも解決すべき多くの問題を抱えている。具体的には、患者データに対するアクセス制御、
患者データの配置、患者データの管理のコスト負担、参加できる施設や事業体、信頼性及びプライバシーに対する責任の所在などに対処しなければならない重要な課題
が、まだまだ残っている。
NHIN は、一部、これまでの RHIO (Regional Health Information Organizations「地域医療情報組織」)モデルと同様の考え方を受け継いでいる。大規模な医療共同体ドメイ
ンによって運用されていた RHIO は、その医療共同体ドメインに誰が参加可能で、誰が参加できないかを決定する。患者のような弱い立場の人々、小規模な診療所、そして地域病院は RHIO の援助の下に置かれ、その好意に頼るという前提で運用され、コストや管理などの問題が表面化していた。
かなりの RHIO は、結果的に成功しなかったため、NHIN は、RHIO と同じ前提で開始しているが、その実装の戦略は異なる。NHIN の機が熟すまでには、まだ何年もかかりそうであり、この異なる戦略が成功するかどうかは現時点ではまだわからない。
NHIN が成功するためには、行政機関、病院、保険者、その他、数多くの参加団体の間で患者データを交換するための語彙、文書、メッセージングなどの標準を定義しておく必要がある。図２－１は、NHIN 構想の全体像である。

14

図２－１ NHIN 構想の全体像（NHIN のプロジェクト）
NHIN は、目的が尐し異なる２つのプロジェクト NHIN CONNECT と NHIN Direct からなる。NHIN CONNECT は、独自に構築した HIE (Health Information Exchange)や、既存の HIE に接続するためのものである。一方、NHIN Direct は、新しいプロジェクトで、他の医療システムとの間で直接データを push/pull するためのものである(必ずしもHIE を使用する必要はない)。図２－２、図２－３は、NHIN 構想の運用基盤の概念図とNHIN のクラウド実装イメージである。
NHIE Zone
NHIN Security Zone

NHIE Network
Services
Registry
Operational
Availability
Monitoring

NHIN Gateway
Security
Infrastructure

NHIN
Operational
Infrastructure

図２－２ NHIN 運用基盤の概念図

15

UDDI
Registry
Cloud

Verisign
Certificate
Authority
Security
Cloud

OAR
Cloud

図２－３ NHIN のクラウド実装イメージ

２．３ NHIN CONNECT
NHIN の主な利用者層は、医療提供者、消費者（個人、患者）、及び NHIN から得られるデータを国民の健康と医療向上のために利用する機関や団体であり、政府、病院、医師、保険者、医療研究所や製薬会社などを含む研究機関など、あらゆる層からのア
クセスを想定している。
このように、多種多様な関係者が、それぞれ異なる目的でアクセスすることが想定されるため、アクセス方法や目的を問わず利用可能な、互換性を備えた接続ソフトウェアが求められる。
CONNECT プロジェクトは、このようなニーズに応えるためのソリューションとして、2008 年から進められてきたものである。NHIN プログラム全体は、標準仕様、参照アー
キテクチャといった大規模なものであるが、それとは異なり、この CONNECT は、それぞれの組織の中で HIE (Health Information Exchange「医療情報交換」) の環境を簡便に構築するためのソフトウェアである。
2009 年 2 月には、SSA（Social Security Administration）社会保障庁が CONNECT を
実際の業務環境で利用し成功を収めた。その後、CONNECT は同年 4 月上旪に一般にオープンソースとして公開された。誰でもソフトウェアを無料でダウンロードすることができ、SDK（Software development kit）も公開されているため各企業が独自にアプリケーションやソリューションを開発することもできる。なお、2010 年 6 月 15 日には、
16

CONNECT version3 が、発表されている。
既存の HIE を医療情報交換の地域ネットワークに組み込むことも、HIE を全国的な情報交換ネットワークに結び付けることもできる。ここで、CONNECT が重点としているのは HIE であり、システム同士を直接接続するポイント・ツー・ポイントのソリューショ
ンではない点に注意を払うべきである(ポイント・ツー・ポイントのソリューションについて
は、次の「NHIN Direct」を参照)。CONNECT の目的は NHIN を HIE に関連付けることであり、EMR を HIE に関連付けたいだけの場合には役立たない。
つぎの３つの基本要素が、CONNECT ソリューションを作り出す（図２－４参照）。
（１）Core Services Gateway
Core Services Gateway は、他の組織の患者を見つめる機能、患者に関連づけられたドキュメントを要求したり、受け取ったりする機能、患者や他の利用者のその後の監査用のトランザクションを記録する機能を提供する。その他の特徴として、ネットワークへの参加者を認証する機構、診療情報の公開に対する許可の方式と認証、それらの情報の共有に対する消費者の意向を尊重する機構などが含まれる。NHIN インタフェース仕様は、このコンポーネントの中で実装される。
（２）Enterprise Service Components
Enterprise Service Components は、電子健康情報交換のサポートに必要な、MPI（Master Patient Index）、XDS.b ドキュメントレジストリ及びリポジトリ、認証ポリシー・エン
ジン、消費者（個人、患者）意向管理、HIPAA 準拠監査ログなどを含む多くの重要なエンタープライズ・コンポーネントのデフォルトの実装を提供する。CONNECT の実装者
は、このコンポーネントを採用するか、同じ目的の自前の既存のソフトウェアを使うかは自由である。
（３）Universal Client Framework
Universal Client Framework は、最先端システムを素早く構築するのに適合した、参照システムとして利用できる。また、Universal Client Framework は、ゲートウェイソリューシ
ョンのテスト用及びデモシステムとして使うことができるアプリケーション群を含む。

17

図２－４ NHIN CONNECT ソリューション

２．４ NHIN Direct
NHIN を短時間で配備するために早急に必要とされるのは、NHIN を利用するための軽量のツール、そして政府がすべてを指定するまで待つことなく、中小企業および大企業が今すぐデータ交換を始められるようにするための簡単な方法である。
トップダウン方式の米国政府の取り組みでは実現に時間がかかること、その一方で、既存のインターネットと現在利用できる企業間プロトコルによって当面の多くの問題を解決できることが判明してきた。
2010 年 6 月には、NHIN の導入促進に向け、国の基準に沿った、正しいセキュリティ
レベルでの医療情報の交換を目的とする NHIN Direct プロジェクトが新設された。
Direct プロジェクトの目標は、インターネット上で認識された信頼できる受け手に暗号化した医療情報を直接送るためのもので、参加者（プロバイダ、検査機関、病院、薬局および患者を含む）のユニバーサルな医療情報の番地付け及び転送を確立するためのセキュアで、スケーラブルな、標準をベースにした仕様を開発することである。
NHIN は、インターネット上でセキュアな医療情報の交換を可能にする標準、サービス、およびポリシーの集合である。この Direct プロジェクト自体は、医療情報の交換サービスを運営するものではない。すでに、いくつかの連邦機関及びヘルスケア組織で、NHIN 標準を使用して、パートナー間で情報を交換している。Direct プロジェクトは、
18

「有意義な使用」の第１ステージのキーになる要求を満たすような標準及びサービスの記述を拡張する。採用を検討しているプロバイダや組織に広く、導入が容易になるようにする。
なお、現在、同プロジェクト内で設けられている作業部会は、以下の 6 つである。
ベストプラクティス作業部会
コミュニケーション作業部会
必要書類、実証作業部会
導入作業部会
リファレンス導入作業部会
セキュリティ作業部会（抽象モデル）NHIN Direct では、サーバ同士の多種多様な対話方法を考慮している。具体的には、
送信元エンドポイントと HISP(サービス・プロバイダ)との間の対話、HISP 同士の対話、送信元と送信先との対話、および HISP と送信先エンドポイントとの対話である。この点に関しては、ハブ・アンド・スポーク・パターンによく似た CONNECT モデルよりも、
NHIN Direct の抽象モデルのほうが、ソフトウェア開発者にとっては馴染みがある。図２－５は、NHIN Direct の抽象モデルである。

図２－５ NHIN Direct 抽象モデル（NHIN コンポーネント）
さらに NHIN の一部には、信頼できる送信元からデータが送信されていること、そして信頼できる送信先にデータが送信されていることを検証するためにデータに署名を付けて認証する。そのための基本的な NHIN コンポーネントには、以下がある。
・認証および証明書
・配信プロトコル
19

・トラスト・フレームワーク
・ボキャブラリー・メッセージ仕様・デイレクトリ・セキュリティ
これらの基本コンポーネントと同じものが、何らかの形でインターネットの中に存在する。データ交換の送信側と受信側の双方が互いを認識していれば、ルーティングおよび信頼性の高いデータ交換に容易に対処することができる。
（アドレス指定）
NHIN Direct でのアドレス指定には、さまざまな形式が考えられる。以下の表は、医療用インターネット・アドレスを (Web サイトから直接) どのような形式で指定できるかを示
す非標準的な例である。
表２－１ 医療用インターネット・アドレス
形式

規則

例

E メール・アドレ
ス

医療エンドポ
イ ン ト 名 +@+医療ドメイン
名

drsmith@nhin.sunnyfamilypract
ice.example.org

REST 実装を参照

https://nhin.sunnyfamilypracti
ce.example.org/nhin/v1/nhin.
sunnyfamilypractice.example.org/drsmith/

この例は、Smith 医師が使用しているメッセージ受信箱を示している。送信側のドメインからは、これと同じ相対 URL を提供できる。v1 は REST API のバージョンを示している。

IHE 実装を参照https://nhin.sunnyfamilypracti
ce.example.org/nhin/1_0/wsdl
s/messages

SOAP Web サ ービ ス を指 す
WSDL を返す。1_0 は、SOAP
API のバージョンを示している。

urn:nhin:nhin.sunnyfamilypract
ice.example.org:drsmith^Smith^John^J^III^DR^PHD^^&NHIN
OID&OID

XCN 表現は、複数のコンテキストで使用することができる。例
えば、XDS/XDR Web サービス
呼び出しや HL7 2.x メッセー
ジの intendedRecipient で、メッ
セージの送信者または受信者
を (PV1 セグメントで) 参照する場合など。

REST URIWSDL 参照

XCN

HL7 文書

20

注記

XON

HL7 文書Sunny Family^^^^^&NHIN
OID&OID^^^^urn:nhin:nhin.
sunnyfamilypractice.example.o
rg:sunnyfamily

XON 表現は、XDS/XDR Web
サービス呼び出しや HL7 2.x メ
ッセージの intendedRecipient
で、メッセージの送信者または受信者を (ORC セグメントで)参照する場合など、複数のコンテキストで使用することができる。

（コンテンツ及び設計）
NHIN Direct プロジェクトでは、構造化されていないコンテンツ (テキスト、PDF など)から半構造化コンテンツ (各種の CDA テンプレート、HL7 MDM など)、さらに完全に構造化されたコンテンツ (CCR、CCD) に至るまで、さまざまなタイプのコンテンツを処理できるトランスポート・レベルの仕様およびサービス一式を作成する。
コンテンツの問題 (例えば、CCD と CCR の違いなど) は、作成された仕様とサービスの記述を基に、プロファイルによって処理される。適格なプロバイダとの接続を組
み込み、さまざまな技術タイプ (インストール済み EHR、モジュール式 EHR、エンター
プライズ EHR、SaaS EHR など) に対応するような設計にする。設計には、インストー
ル済み EHR がファイアウォールを介して外部へのトランザクションのみを行う接続モデル (つまり、プロバイダがオープン・インターネットへの TCP/IP ポートを開く必要のない接続) を尐なくとも 1 つ組み込む。小規模な診療所の典型的な IT 環境 (インストー
ル済み EHR、動的 IP アドレス、IT サポートがないか限られている、などの環境) に対応するような設計にする。
２．５

NHIN 仕様の概要

NHIN で規定されている仕様について、主なものは、以下のとおりである。
[1] Nationwide Health Information Network (NHIN) Retrieve Documents Web Service
Interface Specification V 2.0 1/29/2010
Cross Gateway Retrieve トランザクションのスコープは、IHE XDS (Cross Enterprise
Document Sharing)の Retrieve Document Set トランザクション[ITI-43]に基礎をおいている。Retrieve Document Set トランザクションの多くは、Cross Gateway Retrieve トラン
ザクションによって継承されている。
Responding NHIN Gateways は、IHE XCA (Cross Community Access)サプリメントの3.39 節と 3.39.5 節に記述されているような非同期検索リクエストをサポートしなければならない。(注：3.39.5 節は、IHE の変更要求 420 が承認されて修正され、NHIN でも採択されている) 。
Initiating NHIN Gateways は、同期または非同期 のいずれかの相互呼出しを選択
21

できる。
Query for Documents トランザクションを介して、NHIO (National Health Information
Organizations)は、与えられた患者に対するクエリパラメータを満たす患者レコードに対す
るドキュメントに対する、1 つ以上のドキュメント ID 参照（又はポインタ）を受け取る。
このトランザクションは、要求元が、患者レコード文書を要求するのにその参照を使うことを可能とし、受け側は、ドキュメントをセキュアに、要求元に返すことを可能にする。
さらに、ドキュメントの検索の監査を可能にする。詳しい相互作用図は、IHE XCA 統合
プロファイルにある。
Retrieve Documents Set トランザクションは、つぎの３つのステップで記述される。各ステップは、XCA サプリメント 18.3.3 節に記載されている。
(1) Document Consumer
ドキュメントコンシューマは、Retrieve Document Set を起動する。Retrieve Documents
Set トランザクションの起動側が、XDS アフィニティドメインではない場合も、トランザクシ
ョンの起動は、内部的及び機能的には同等の方法で行われる。
(2) Initiating Gateway
Initiating Gateway は、適切な Responding Gateway を Cross Gateway Retrieve による
Retrieve Document Set を処理する。
(3) Responding Gateway
Responding Gateway は、Cross Gateway Retrieve を処理する。XDS アフニィティドメイン
内 で 、 Responding Gateway は 、Document Consumer とし て グル ー プ化 し Cross
Gateway Retrieve を処理する。リクエスト内の一意なリポジトリ ID によって識別されるドキュメントリポジトリに対して、Retrieve Document Set トランザクションを起動する。Cross
Gateway Retrieve が、異なる一意なリポジトリ ID で、多重のドキュメントをリクエストする
なら、Responding Gateway は、多重のドキュメントリポジトリに接続し、その返答を集約しなければならない。
[2] Nationwide Health Information Network (NHIN) Query for Documents Web Service
Interface Specification V 2.0 1/29/2010
NHIN Query for Documents は、HITSP TP13 の一部である ITI-38：Cross Gateway
Query トランザクション IHE Cross Community Access (XCA)を使う。NHIN の XCA プロ
ファイルは、もとの IHE ITI-TF（IT Technical Infrastructure Technical Framework）に、要求事項が追加されたものである。XCA ITI-38 仕様は、動的に生成されたドキュメント
コンテンツに対する検索および取り出しをオプションとしてサポートして あるが、この
22

NHIN 仕様では緩くしている。
[3] Nationwide Health Information Network (NHIN) Patient Discovery Web Service
Interface Specification V 1.0 01/29/2010
NHIN Patient Discovery は、IHE ITI-55: Cross Gateway Patient Discovery (XCPD) ト
ランザクションを使う。まず、XCPD は、まだ HITSP によって評価されていない。XCPD
は、この NHIN 仕様内では記述されているトランザクションモードの１つを除外するように制限している。さらに、NHIN は、3.1.6 節“Returning Multiple Entries”で記述されているように、割り当て機関ごとに１つのエントリを返すように XCPD を制限している。
[4] Nationwide Health Information Network (NHIN) Document Submission Emergence
Pilot Web Service Interface Specification V 1.1.0 10/26/2009
NHIE （National Health Information Exchange） Core Services は、2007 年 5 月 31 日に ONC に対する NHIN プロトタイプアーキテクチャのガートナー報告に記載されている。
Data Services：、EHR、PHR、他のシステム及びネットワークに対して、セキュアなデータ
配信、及び配信の確認。XDR (Cross Enterprise Document Reliable Interchange)は、IHE ITI TF Revision７ 2010-8-10 Section 18 に記載されている。Document Source としての NHIE を起動し、Document Recipient として NHIE が受け取る。このトランザクショ
ンは、NHIE を起動する方も、受け取る方も XDS アーキテクチャを必要としない点が重要である。言い換えると、Document Recipient は、XDS Registry にドキュメントを登録し、ドキュメントソースからのドキュメントを受け取る際に、それを XDS Repository に格納する必要はない。
[5] Nationwide Health Information Network (NHIN) Authorization Framework
Specification V 2.0 1/29/2010
NHIN 認証基盤は、OASIS SAML(Security Assertion Markup Language) V2.0 及びSAML の医療に対するプロファイル XSPA（Cross-Enterprise Security and Privacy
Authorization）をベースとしている。
[6] Nationwide Health Information Network (NHIN) Web Services Registry Web Service
Interface Specification V 2.0 1/29/2010
このドキュメントは、NHIN Web サービスレジストリの実装及び利用に焦点を当てている。
UDDI（Universal Description and Discovery Interface）v3.0.3 に対する OASIS 仕様をベースにしている。この仕様は、以下からなる。
・質問及び申込みのインタフェース及び機能・レジストリのエントリを格納するための使用されるデータモデル
23

・サービスレジストリに対して、NHIN により使われる階層的な複製戦略
２．６ 「有意義な利用」について
HITECH 法は、MU (Meaningful Use「有意義な利用」)という新しい用語を作り出し、医療 IT 業界の流れを一新した。一連の規制のなかで、再生法 (Recovery Act) では具
体的に以下の内容を要件としている。
・公認 EHR (Electronic Healthcare Record「電子健康記録」)を「有意義な」形で使用すること (NHIN には直接関係なし)
・公認 EHR を健康情報の電子交換に使用すること (NHIN にとって重要な点である)
・公認 EHR を使用して、臨床上の品質やその他の評価基準を政府に送信すること(同じく NHIN を使用して送信される)
MU は、素晴らしい概念で、この手法で意図されているのは、情報システムを単に導入するだけという業界の流れを、実際に情報システムを使って患者の生活を向上させるという流れに変えることである。
MU は、データの収集と共有 (NHIN は、企業外部でデータを共有する際に活躍する) から高度な臨床プロセス (NHIN による改善を加えたプロセス) へと移行し、さらに最終的には改善された成果 (NHIN によって政府に報告することができる) をもたらすことを目的としている。
MU を定義している人々は、必要最低限以上の情報共有、そして臨床ワークフロー
における大きな改善なくして、医療成果の改善は望めないことを理解している。
医療成果の改善に MU が最終的にどれほどの影響を及ぼすのかは未知数だが、滑り出しとしては順調である。
MU の規定を作成するなかで、MU は 3 ステージに分けて定義された。ステージ
1 は 2011 年、ステージ 2 は 2013 年、ステージ 3 は 2015 年である。ステージ 1
では、NQF (National Quality Forum 「全米医療品質フォーラム」) が、以下の健康ア
ウトカムの優先事項に取り組むことになっている。
・品質、安全性、効率性の改善、および医療格差の縮小
・患者とその家族の健康管理への関与
・医療協調の促進、公衆衛生の改善
・健康情報に対する適切なプライバシーおよびセキュリティ保護の保証（MU の目標と NHIN）
最終的な MU の規定は、2010 年 7 月 13 日に HHS によって公開された。この規定
では、「有意義に利用」していると認められ、奨励金の受給資格を得るために病院が満たさなければならない 24 の目標および基準が定義されている。
そのうち、「コア・セット (core set)」はすべての医療機関が達成しなければならない
24

目標である。一方、「メニュー・セット (menu set)」については、医療機関はそのうちの 5
つ以上の目標を達成する必要がある。以下に、医療機関が認識すべき MU 基準をリストアップする。NHIN に直接関連する目標、または多尐なりとも関連する目標には[NHIN] と追記している。
（コア・セットの目標）
以下は、すべての医療機関が達成しなければならないコア・セットの目標である。
・CPOE (Computer Provider Order Entry) を使用すること
・薬剤相互作用、薬剤アレルギー、採用医薬品集のチェックを実施すること・患者の年齢層統計を記録すること
・1 つの臨床決定支援規則を実施すること・ICD-9-CM または SNOMED CT に基づき、現在進行中の診察の問題リストを最新の状態に維持すること・実際に使用している医薬品のリストを管理すること・実際に使用している医薬品のアレルギー・リストを管理すること・バイタル・サインの変化を記録およびグラフ化すること・13 歳以上の患者の喫煙状況を記録すること
・病院の臨床品質の評価基準を CMS または政府に報告すること [NHIN]・患者からの要請に応じて、患者の健康情報の電子コピーを提供すること [NHIN が関連する可能性有]・患者からの要請に応じて、患者の退院時に退院指導の電子コピーを提供すること［NHIN が関連する可能性有］・医療プロバイダや患者が許可した機関の間で重要な臨床情報を電子的に交換できる
こと [NHIN]
・電子健康情報を保護すること（メニュー・セットの目標）
以下は、メニュー・セットに挙げられている 10 の目標である。各組織は、このうち、5つ以上の目標を達成する必要があり、そのうちの 1 つ以上は公衆衛生に関する目標(⑧、⑨、⑩) でなければならない。
① 採用医薬品集のチェックを実施すること② 65 歳以上の患者を対象とした高度な指示を記録すること③ 臨床検査試験の結果を構造化データとして組み込むこと④ 特定の条件を基準にして患者のリストを作成すること [NHIN で支援可能]⑤ 公認 EHR 技術を使用して患者に固有の教育資料を特定し、必要に応じて患者に提供すること [NHIN で支援可能]
25

⑥ 薬剤の緻密な確認を行うこと [NHIN が関連する可能性有]⑦ 治療段階が遷移するごと、あるいは専門医へ委託されるときに治療記録を要約す
ること [NHIN で支援可能]⑧ 予防接種登録情報システムに電子データを送信できること [NHIN]⑨ 報告義務のある検査結果を公衆衛生当局に電子的に送信できること [NHIN]⑩ 症候に関して観察されたデータを公衆衛生当局に電子的に送信できること[NHIN]
個々の選択を尊重したセキュアな健康情報の交換を可能にする、信頼性のある構造。
この構造には以下のものが含まれる。
・セキュア・トランスポートを保証するインターネット・ベースのプライベート・ネットワーク
・有効かつ信頼できる団体のみが参加できるようにするためのメンバーシップ・サービス
・団体間の相互運用性を確実にするための認定
・情報交換のプライバシーおよびセキュリティを保護するための法的取り決め
・ネットワーク参加者にネットワーク上のリソースへのアクセスを可能にする、監督された
インデックス一式
・すべての参加団体の活動、役割、責任を構造化して定義し、責任説明を課すガバナ
ンス・モデル・NHIN のミッションとガバナンス構造により結束された団体からなる連合 (NHIE)
２．７ 世界の動向との関係
米国の NHIN 構想で採用されている IHE の XDS（Cross-Enterprise Document
Sharing）などの技術は、先行するカナダ及びフランスなどの国家プロジェクトともに、技術を発展させ共有するものである（表２－２）。
また、EU では、IHE ベースで NHIN と同様な構想のプロジェクト epSOS（European
Patients Smart Open Services）が進められている（図２－６）。

表２－２ 主な医療 IT ネットワークプロジェクトの動向
国・地域
カナダ

動向
カナダの健康 Infoway プロジェクトで、XDS を画像が扱えるように拡張して XDS-I を開発した。
XDS-I を使用することで、大容量となる PACS の DICOM データを複製することなしに、多施設からリアルタイムに参照することができる。
http://www.infoway-inforoute.ca/lang-en

フランス

IHE フランスは、ASIP ' Santé との共同の作業部会を設けて活動している。ASIP'Santéは、保健省からの委託を受け電子医療記録 （DMP） を実装するプロジェクトを管理し26ている。また、ガイドラインを定義し、製品及び相互運用性、セキュリティ、医療及び e健康 IT システムの使用を、保健省の承認の下で支援するサービスを普及させる。
http://www.ehealtheurope.net/Features/item.cfm?docId=194
http://esante.gouv.fr/en/contenu/electronic-health-record-dmp-changing-developm
ent-software-healthcare-professionals
EU

epSOS（European Patients Smart Open Services）は、EU の eHealth プロジェクトで、
XDS など IHE 仕様をベースに、米国の NHIN と同様のアーキテクチャでプロジェクトが進められている。広域の連携には XCA を使用している。12 の EU 加盟国が参加している。IHE ヨーロッパでは、ヘルスケアの企業 35 社の部門間で、国境を越えたサービスを展開し、海外旅行やビジネス旅行の際、国または地域の国境を越えて安全で効
率的な医療を提供することを保証する。ヨーロッパでは、患者のサマリ、特に基本的な患者サマリ と 、さ ま ざま な国や地域のシ ステと eHealth ビジネ ス サービス会社（eHBS）間で相互運用性を実現する必要がある。
http://www.medetel.lu/download/2010/parallel_sessions/presentation/day3/Medical_
Data_Exchange_Solution.pdf

図２－６ epSOS（Smart Open Services for European Patients）[参考文献][1] An overview of NHIN and NHIN Direct for software developers
Shahid N Shah, CEO and Chief Architect, Netspective Communications, LLC
http://public.dhe.ibm.com/software/dw/web/wa-nhindirect/wa-nhindirect-p
27

df.pdf[2] 「ソフトウェア開発者のための NHIN および NHIN Direct の概説」
Shahid N Shah, CEO and Chief Architect, Netspective Communications, LLC
http://www.ibm.com/developerworks/jp/web/library/wa-nhindirect/index.ht
ml[3] 「米国における医療 IT に係る標準化とプライバシーに係る動向」ニューヨークだより(IPA)2009 年 6 月 市川類＠JETRO/IPA NY
http://www.ipa.go.jp/about/NYreport/200906.pdf[4] 「米国における医療分野の IT 導入に係る動向」ニューヨークだより 2010 年 9 月
増刊和田恭＠JETRO／IPA NY
http://www.ipa.go.jp/about/NYreport/201009-1.pdf[5] 「米国政府における EHR の最新動向」米国マンスリーニュース 2009 年 2 月号
http://e-public.nttdata.co.jp/f/repo/605_u0902/u0902.aspx

28

第３章

NIST のクラウド定義とクラウドの現状

クラウドの時代には、地域医療連携や読影ネットワークに大きな発展が期待されるが、なかでも、IHE－XDS を活用することが有用であると思われる。クラウドは様々な視点から述べられているが、本稿ではＮＩＳＴにおけるクラウドの定義をふまえつつ、クラウド供給者からみた医療分野における IHE－XDS 活用の観点から現状を説明する。
一方、クラウドの利用者である医療機関は、情報セキュリティと個人情報保護にかかわる課題の検討が必須である。特に、その観点から検討を進めたい。
３．１

クラウドの定義

クラウドとは、極めて膨大なネットワーク・サーバ・ストレージ・業務プログラム・サービス等からなる「IT リソース」を保有するサービス事業者が、多種のクライアント（PC、携帯電
話、スマートフォン、家電、ビデオカメラ、ドアホン等）から有線・無線のネットワーク経由
でアクセスする利用者をマルチテナントの環境でサポートするサービスである。
スケールイン・スケールアウトでき、記憶装置、処理装置、帯域、及びアクティブなア
カウントなどの使用量を計量し、その量に応じた料金を請求できる仕組みを保有している仕組みを、クラウドと定義している。ちょうど、電化製品を電力コンセントでつないだらすぐに稼働できるのと同じような感覚である。クラウドの定義で最も有力と考えられている NIST の定義を要約すると、下記の５項目になる。
注） NIST：National Institute of Standards and Technology Information Technology
Laboratory（米国国立標準技術研究所,情報技術ラボラトリ）(1) 利用者が必要なときにＩＴリソース（ネットワーク、サーバ、ストレージ、業務プログ

ラム、サービス等）を利用でき、その際、サービス提供事業者の担当者による作業が不要。
(2) ＩＴリソースはネットワーク経由で入手でき、お勧めの標準的プロトコルにより、種々のクライアント（例えば、携帯電話、ノートブック PC 及び PDA）でアクセス可能。
(3) クラウドのＩＴリソースは、利用者のニーズに応じて動的に割り当てられ、物理的／仮想的なＩＴリソースがマルチテナント（複数利用者）でプールされる。利用者
は、ＩＴリソースの位置制御に関する知識が全くなくても、高度に抽象化された位置が割り当てられ、物理位置（例えば、国、州、またはデータセンタ）から独立である。
(4) ＩＴリソースは伸縮自在で、自動的・迅速にスケールアウト・スケールインし、リリースされる。利用者に提供される機能は、いつでも無限に購入できる。
(5) クラウドは、サービスタイプを抽象化して計量機能を配分し、ＩＴリソース使用の29

自動的なコントロールと最適化を行う（例えば、記憶装置、処理装置、帯域、及びアクティブなユーザカウント）。ＩＴリソース利用状況は、提供事業者とサービス
利用者の両者にとって透明性があるように、監視され、制御され、報告される。
上記クラウドの定義は、クラウドと呼ぶべき最低限の機能であるが、クラウドビジネスのこれからの発展にとって重要なことは、将来性のあるキラーアプリないしコンテンツが開発されることと、クラウドデバイスの多様化であると言われている。
前者のための大きな可能性は、オープンソース方式によるアプリケーション開発である。医療分野においても、現在のままでの特定企業の開発するアプリケーションソフト
ではなく、openEHR 等のオープンソースによる業務システム開発形態が大きな発展をもたらす可能性が指摘されている。また、グーグル社のアンドロイドもオープンソース戦
略を取っているため、安価で多様なクラウドデバイスを供給できる可能性がある。
ただし、オープンソース戦略については、①収益モデルの構築と、②情報セキュリテ
ィ、特に、完全性・可用性に関するコミットメントの２つが課題として残っていると考えられる。
後者の、クラウドデバイスの多様化の促進と言う観点からは、ネットワークの IPV6 化が進展することが重要である。現行の IPV4 と IPV6 の比較を下記する。

表３－1： IPv4 と IPv6 との比較
ＩＰｖ４（現行）

ＩＰｖ６（次世代）

ＩＰアドレス空間

３２bit(約 43 億個）

１２８bit（約 3.4*1026 個)

アドレスの割り当て

アドレス設定が煩雑

機器固有アドレスの割り当てとネットワーク
アドレスの自動付与

パケット転送のデータ伝送に種別なし

フロー制御と通信種別（文字・画像・音声）効率化
セキュリティ

のフイールドの採用
セキュリティは未整備（元来は研ホスト間での高いセキュリティ

究目的のプロトコルのため）
処理速度

パケット列の識別がＩＰ層のみでは パケットのヘッダフイールド構成の見直し
不可により高速化

この結果、例えば、すべての家電製品や車などに IP アドレスを設定することも、医薬品や衣服のようなすべての商品にＲＦＩＤタグ等による識別アドレスを付けることも可能になる。
また、IPV6 の高いセキュリティ機能を活用した業務システム運用を活用し、安全・安心
30

なネットワークの構築が期待できる。
３．２ IHE-XDS の一般的事例
クラウドサービスは、地域医療連携のような参加機関数やデータ量、端末設置台数等、ボリュームの見通しが困難で、変動が激しいビジネスモデルには最適のサービスである。
IHE-XDS は、地域医療連携の運用主体がレジストリサーバを運用する。一方、連携する各医療機関が自機関の運用する連携用リポジトリの中に、電子カルテや医用画像
情報の診療記録を格納しておく。情報を必要とした機関がレジストリを経由して当該の患者情報を検索し、吸い上げることにより地域医療連携を行う。
これら、リポジトリやレジストリをクラウドが包含すれば、極めて柔軟な地域医療連携モデルが実現できると思われる。
現在、IHE-XDS は国内でいくつかの事例があるが、すべて、ひとつの地域で単一のレジストリを持ち、コンソーシアムがひとつのポリシーで地域連携の全体を管理している。
これは、IHE-XDS を採用していない他の地域医療連携にも共通するものといえる。
今後の地域医療連携モデルでは、地域医療連携組織が複合して存在し、例えば、周産期連携・脳外科連携・糖尿病連携・整形外科連携など、中核となる医療機関が混在し、参加する医療機関は複数のレジストリに対応することが必要となることが想定される。
これらは、図３-１のように、同一のクラウド上にも、異なるクラウド上にも搭載されることが考えられ、IHE-XDS のように標準化された IHE のプロファイルが望ましい。
電子保存についてはクラウド上で実現することも可能と思われるが、現在のところ、様々な課題があるため、標準的なクラウドで安全管理ガイドラインで求められている３原
則や機能を満たすことは困難である。このモデルの中では、診療所等、小規模医療機
関の診療データをクラウドの外で預かる方法を表現した。３．３に詳述する。

31

IHE-XDS地域医療連携モデルの概念図
連携用
カルテ
データ

地域医療
ＤＢセンタ１

がん中核
医療センター

糖尿病中核
医療センター

連携用
レジストリ

連携用
カルテ
データ

連携用
カルテ
データ

脳外科中核
医療センター

連携用
レジストリ

連携用
レジストリ

ＸＣＡ

地域医療
ＤＢセンタ２

電子保存用
預託データ

紹介状データ（ナマデータなし）

連携用
リポジトリ

連携用
リポジトリ

地域医療
ＤＢセンタ３
Ａ診療所

医用画像
データ

Ｂ病院

連携用
リポジトリ

院内用
電子カルテ
データ

Ｃ診療所

電子保存
ＤＢセンタ４
Ａ診療所用
医用画像
電子カルテ
データ
データ
Ｂ診療所用
医用画像
電子カルテ
データ
データ

図３－１ IHE-XDS 地域医療連携モデルの概念図
今後の IHE-XDS を活用した地域医療連携を PULL 型としてモデル化し、従来の地域医療連携（PUSH 型）と比較すると、下表のとおりとなる。
表３－２ IHE-XDS による地域医療連携モデルと従来の連携 DB センタ
１． これからの地域医療連携：ＰＵＬＬ型：IHE-XDS① 地域の診療所は紹介すべき患者の ID を紹介状データとして中核医療機関に伝送する。
② 中核となる医療機関は紹介状データを元に、外部データセンタにあるデイレク
トリを検索し、リポジトリから専門家としての医療知識から実データを必要な分のみ吸い上げる。
③ 個人の医療情報は必要なデータのみが分散保管される。
④ 地域の診療所は電子カルテを運用するが、望むならば民間委託で運用する電子保存センタに電子保存用のカルテ情報を預託できる。
２． 従来の地域医療連携：ＰＵＳＨ型:CD 紹介状例
① 地域の診療所は、紹介状ＣＤとともに、必要と「勝手に考える」医療情報を添付して送付する。

32

② 中核となる医療機関は診療以外に連携ＤＢセンタの運用の負荷が加わる③ 個人の医療情報は、複数の連携ＤＢセンタに分散保管される。
④ 地域の診療所は電子カルテを運用し、電子保存を満たす運用の義務を負う。

このような複合型地域医療連携における IHE-XDS の課題を検討すると、（１） 例えば、糖尿病と癌と脳外科の３つの連携医療のネットワークが、ある地域内に個別に存在した場合、レジストリは、その地域にひとつのみ存在する以外に、
XCA を活用する方策が考えられる。当初からすべての連携を考慮に入れてレジ
ストリの構造を検討しておくことが困難、もしくは検討に時間を要すると考えられる。
（２） 個人を一意で特定できる ID は、そろそろ、国民的合意を得られるレベルに達しているが、それが設定されたあかつきにも、地域医療連携レジストリが複数存在す
る意義・可能性が想定され、その際の技術上・運用上の課題は検討しておく必要がある。
（３） 例えば、糖尿病と癌と脳外科の３つの連携医療のクラウドが出来た場合、参加する側の医療機関のリポジトリの設定は、他の連携モデルへのセキュリティに関して
特に、配慮が必要となる。例えば、下記のような検討が必要であろう。
 複数の連携医療に参加する医療機関（診療所等）は、リポジトリをひとつだけ作れば良いか？３つ作る必要があるか？
 その際、他の連携クラウドに行くべきでない情報の漏洩がない処置は何か？
３．３ クラウド環境での院内電子カルテと IHE-XDS による地域医療連携クラウド環境を概括的に、クラウドサーバ・クラウドネットワーク・クラウドデバイスに分け、それぞれでの脅威と脆弱性を考えてみる。
（１） クラウド環境のガバナンスに関する脅威と脆弱性の考え方① 安全管理ガイドラインでのＡＳＰセンタの容認
安全管理ガイドライン（「医療情報システムの安全管理に関するガイドライン V4.1」厚
生労働省：2010 年 2 月発行 以下、同じ）では、当初、自機関内にある専用のサーバ
で電子カルテを運用することを前提とし、次いで、2010 年 2 月に改訂された安全管理
ガイドライン V4.1 で、病院外部の安全なＡＳＰセンタに電子カルテを格納することを容認することになった。ＡＳＰセンタの場合、サーバの位置は国内（正確には、日本国の主権の及ぶところ）に特定することが要求されている。永らく、電子カルテは単独の病院内で運用することが前提とされてきたところから、ハードデイスク上の電子カルテデー
タは、当該機関の運用停止後一定期間、他機関のデータが入ることはないとの前提で考えられていたと想定される。
33

② クラウドサーバに活用の課題に関する脅威（Ａ）医療機関の電子カルテサーバないしは地域連携用のレジストリ・サーバをクラウド化することは、コストダウン・可用性の観点からメリットが大きいが「サーバの位置が国内に特定できない」ことになり、具体的には、
ａ）裁判権が海外に及ぶ可能性ありｂ）日本国の捜査権が及ばない場合ありの２つのリスクが想定されるようになる。そのため、すくなくとも、証拠性の観点からの長期保存用電子カルテは国内ＡＳＰ等にバックアップ的に保存することが求められる。保
存の時間間隔とタイミング（例えば、「毎日、差分を保管する」等）については、別途検討が必要である。
（Ｂ）医療機関の電子カルテサーバないしは地域連携用のレジストリ・サーバを、クラウドによるマルチクライアント化することは、構成の柔軟性・安価・サービス多様化の面からは非常にメリットが大きい。一方、安全管理ガイドラインではデバイスを活用後廃棄する
場合、「技術的に安全（再生不可）な方式で破棄を行う」となっているが、クラウドサーバ
では、
ａ）ハードデイスクの破壊等によるデータの消去は実務上不可能ｂ）他クライアントによる進入の脅威が消えないなどの機密保護上の課題が残る。
ｃ）クラウドの場合、可用性のコミットメントが困難なため、現在は価格で補償する方式を取っているところが多い。クラウド側がマルチクライアントを採用する一方で、利用者側
はマルチクラウド化で２重化することがリスク軽減の一策といえる。医療機関の緊急事
態対応から、データ２重化の検討が必要である。
（２） ネットワークの機密保護・性能低下のリスクに関して自前で機器を保有する場合やＡＳＰセンタの場合でのネットワークに関しては、主要回
線を専用回線化できるし、インターネット回線と院内回線を物理的に分離することが可能であるが、コストがかかる。
一方、クラウド環境では、サーバすら海外に設置される可能性があるゆえに、ネットワ
ークはサーバ・クライアント間ばかりでなく、サーバ・サーバ間であってすら、インターネ
ット回線を経由となる可能性が不可避となる。
安全管理ガイドラインでは、院内 LAN でインターネットに出ることのできる回線と院内回線を明確に（できれば物理的に）分離することを求めているが、クラウドでは無意味である。それゆえに、経路特定の保証（例えば、機密保護面からの「海外経由不可」、
レスポンス面からの「衛星回線の禁止」等）が得られない可能性があるため、暗号が解34読されるリスク・レスポンス悪化のリスクが考えられる。
（３） クラウドデバイス（クライアント端末）
自前で機器を保有する場合やＡＳＰの場合では、クライアント端末機種に限定があり、端末運用場所が院内等に限られる。
クラウド環境では、従来のＰＣやノートパソコン以外に、ＩＰＡＤやアンドロイド携帯をはじめとする、多様なクライアントを活用できることがクラウドの特徴だが、Windows やオー
プンソフトデバイスのため、ウイルス侵入の脅威がある。
クラウドデバイスの運用場所を限定されず、「業務用クライアント」に限定しないで操
作者が自ら最適のクライアントを選定することでクラウドのメリットを最大限に生かすことができるが、その一方、完全性・可用性に脅威が考えられる。
（４） クラウド形態別（SaaS、PaaS、IaaS）の個人情報保護法上の課題① SaaS 活用上の課題
SaaS ベンダ提供の業務システムを利用機関側が採用するため、業務システムの開発・維持要員が不要になるという、大きなメリットが得られるが、その一方、クラウド業者の業
務システムが SaaS ベンダの都合で、バージョンアップと称して勝手に変更される可能性がある。
プライバシーマーク認定指針及び安全管理ガイドライン V4.1 では、業務を委託する
利用機関は、下記に留意する必要があるとされる。
1. 委託先クラウドの選定・評価
2. クラウドへの委託業務の発注、進捗管理 、検収
3. 利用機関・組織内で、委託目的の明確化
4.
5.
6.
7.
8.

委託する個人情報の取得・提供に関する同意の獲得
再委託等、クラウド委託先との契約条項の留意
委託先からの業務状況の報告へのレビュー
委託先クラウドへの監査、場合により立入り委託目的終了時の個人情報の削除等の確認

しかし、特に５～８項はクラウドベンダー相手には困難で、SaaS が前提ならば、本当に信用の置ける SaaS ベンダーを選定し、患者等に「個人情報の提供」の同意を獲得することが実務上の近道ではないだろうか？
その場合も、利用者がクラウドシステムの採用・変更に当たって、自機関の業務分析及びテストを行い、必要な信頼性を確保する必要があることは当然である。
現在、業務パッケージの採用やＡＳＰベンダシステムに業務運用を委託する際も、利用者側で十分な業務分析・テストが行われているか？については、よく反省すべきであ35

る。
② PaaS 活用上の課題
現在の院内または地域医療連携の業務アプリケーションと運用をクラウドに移行するた
め、サーバ及びサーバ運用要員が不要だが、開発体制は必要である。
しかし、PaaS の場合でも、委託の場合は SaaS と同じ課題があるため「個人情報の提供」の形態が望ましい。
③ IaaS 活用上の課題
現行の業務アプリケーションをクラウドに移行し、運用は利用機関・組織が行うため、ハードと基本ソフトが不要だが、運用体制・開発体制は維持する必要がある。
IaaS の場合でも、委託の場合は、SaaS・PaaS と同じ課題があるため「個人情報の提供」の形態が望ましい。
３．４
ティ

クラウドの ISMS 対応による国際標準化と個人情報保護・情報セキュリ

日本は、1995 年に制定された EU-directive(欧州連合の法律)へのデータ保護指令の対応として、個人情報保護法を 2003 年に制定し 2005 年に全面施行した。しかしなお、「日本は十分なレベルの保護を提供している国であるとは、まだ考えられていない」［2009 年 4 月のデータ保護に関する会議（開催地：ベルギー）で欧州委員会の法務担
当者の発言］状況である。
そのため、個人情報の十分な保護措置を行われていない国へは、欧州からプライバ
シー・個人情報の送信を禁じられている状況である。なお、米国は２０００年のＥＵとのハーバー合意により、特例的に個人データの送信を認められた。
また、現在の個人情報保護法には、データを海外に送信する場合の取り扱い規程も無い。このままでは国境を越えてデータが行きかうクラウドコンピューテイングの時代には、日本は競争力を失ってしまう。［以上、2011 年 2 月 1 日付け朝日新聞夕刊（メデイ
ア激変 201）］
保健医療情報に関する、個人健康情報保護の観点からは、ISO22857:2004（健康情報システム：個人健康情報の国境を越えた流れを容易にするためのデータ保護のガイドライン）が重要であり、関連各組織各々はもとより、国を挙げての対応が必要となる。
３．５ ISMS 標準化の活動とクラウド
クラウドへの対応に関しては、ISMS（情報セキュリティマネジメントシステム）を検討する
ISO の SC27 で ISMS から見たクラウドの検討が最重要課題として急がれており IS（国際規格）化よりも TS（ Technical Specification： 技術仕様書)にしてでも発行することが計画されている。WG１は、日本が主査となることが２０１０年１０月のベルリン会議で決定し、本年４月のシンガポール会議で検討が開始される。これは、日本が ISMS の超最大の36

認証取得国（全世界の約６０００件の ISMS 認証組織のうち、実に３５００件が日本国内！）であることから、ISMS の件に関しての発言力は強いとされているからである。そこ
で、経済産業省は「クラウドサービス利用のための情報セキュリティマネジメントガイドラ
イン(案)」をベースにその対応を行う予定である。
また、WG４は情報セキュリティ、WG５は個人情報保護 を検討する。ISMS の観点から情報セキュリティと個人情報保護は同じ土俵で検討される。
３．６ クラウド利用の保健医療機関における「ISMS の実践」
ISMS は、ISO/IEC２７００１（情報技術―セキュリティ技術―情報セキュリティマネジメント
システム要求事項）に、要求されている事項を実践し、情報セキュリティをマネジメント
することであり、その主な実施事項は、表４－３のとおりである。
表４－３：ＩＳＭＳにおける PDCA サイクル
PLAN:ISMS の確立① ISMS 構築のための体制準備② リスク評価手法の確定と評価実施③ ISMS と個人情報保護の内部規程等の作成
DO：導入・運用① 情報セキュリティ・個人情報保護教育② ISMS の運用の記録③ 有効性の測定と見直し
CHECK：監視及びレビュー① 監視・見直しのための手順・管理策の実施② 定期的な内部監査と不適合の指摘③ マネジメント・レビューを定期的に実施
ACT：維持・改善① ISMS の維持と継続的改善と是正措置・予防措置

情報セキュリティでは、金融・通信・医療分野は特に留意すべきとされており、それぞれ、各分野向けの規格が存在する。医療分野は ISO27799:2008（健康情報システム：
ISO/IEC27002 を活用した、ヘルスケアにおけるセキュリティマネジメント）である。
リスクマネジメント（リスク手法の確立と評価・実施）に関しては、ISO/IEC27002 の他に、医療分野の ISO27799、及び、これから策定される「クラウド ISMS」を考慮に入れて、
リスクマネジメントを実践することが求められると考えるべきである。
安全管理ガイドラインは、本来、保健医療分野における個人情報保護の観点から作37

られているため、主に「個人情報」の「機密性」の観点が中心に述べられており、個人情
報以外の情報資産の「完全性」「可用性」に関する観点が不足しているように感じている。
例えば、ISO27799:2008 においては、「保護されるべき健康情報」として、下記の項目が挙げられている。
表３-４ 保護されるべき健康情報（ISO 27799：2008 より：森口訳）
1. 個人健康情報
2. 個人健康情報から由来する連結可能匿名化情報
個人特定情報はどこかに存在し、個人情報に遡れる
1. 統計的及び研究情報のような連結不可能匿名化情報
個人健康情報から個人特定情報を取り除いたもの
1. 臨床及び医学上の知識、特定の患者ないしは患者群にかかわらない臨床上の判定支援情報
例：医薬品の副作用情報
1. 健康専門家及びそのスタッフのデータ
2. 健康調査にかかわる情報
3. 健康情報システムの監査証跡データ、または個人健康情報に関する利用者のアクション
に関するデータ

特に、地域医療連携、産業保健連携による国境を越えた健康情報連携、及び、国際的医学研究連携を行うことが、国民医療にとって喫緊の課題と考えられている現在、
これらの連携を推進する上で、クラウドへの対応行う際に、個人情報保護・情報セキュリ
ティの観点から、これらの ISO を活用した「ISMS の実践」を行う必要がある。
一方、安全管理ガイドラインにおいては、保健医療機関における「ISMS の実践」がう
たわれており、「ISMS を実践する」ということは、表 3 の ISMS の PDCA に関する一連の項目を実践することである。とりわけ、① 情報資産の特定とリスク分析、② 内部規定の策定、③ 内部監査と経営者によるマネジメントレビュー
は、「ISMS の実践」には必須であるにもかかわらず、過半の機関で実践されていないのが現状である。特に、機微名個人情報を大量に取り扱う保健医療機関においては、下記の観点に特に留意して ISMS を実践すべきである。
① 情報資産の特定とリスク分析：
職員自らが自分の積極的な意識を持って、身にしみてリスク分析を行った過程と結果
38

が重要である。
② 内部規程の制定：モデル的な規程を導入することは良く行われているが、継続的に自組織の身の丈にあった規程に熟成してゆく必要があり、一朝一夕に実践できるものではない。
③ 内部監査：内部監査員を、長期間に渡りじっくりと育成・訓練を行うことが求められる。これらは、連携医療においても、当然、同様である。
地域医療連携の実証実験は、既に１０年前から実施されたが、殆どの実証実験が泡沫に帰している状態であるが、これは、実証実験が技術的な面からの実験にとどまり、地域医療連携のマネジメントの実践が十分に行われていないためと考えられる。
その中では、特に、国際的な個人健康情報交換の観点から、各国の個人情報保護
法制と情報セキュリティを相俟って検討することが重要である。
［参考文献］[1] クラウド時代の情報セキュリティ：NRI セキュアテクノロジーズ編：
日経 BP マーケテイング 2010 年 8 月 9 日[2] クラウド：小池良次：インプレス R&D 社 2009 年 3 月 1 日[3] ePHDS 委員会/日本 PACS 研究会 & 日本 IHE 協会 編:地域医療連携情報シス
テム構築 ハンドブック 2010―IHE XDS による HIE（Health Information Exchange）の構
築― 2010 年 3 月 http://www.jpacs.jp/book2010.pdf[4] 経済産業省：「クラウドサービス利用のための情報セキュリティマネジメントガイドラ
イン（2011 年 4 月 1 日 策定）の公表～クラウドサービスの安全・安心な利用に向けて」
http://www.meti.go.jp/press/2011/04/20110401001/20110401001.html[5] 総務省：「スマート・クラウド研究会報告書」 2010 年 5 月 17 日
http://www.soumu.go.jp/menu_news/s-news/02ryutsu02_000034.html[6] NIST のクラウド定義（NIST Definition of Cloud Computing v15） 2009 年 10 月 7
日 http://csrc.nist.gov/groups/SNS/cloud-computing/index.html[7] 医療・介護 個人情報の保護と活用の手引き：法研 2005 年 4 月[8] 産業保健版 個人情報の保護と活用の手引き：法研 200７年 2 月[9] 医療情報セキュリティマネジメント（ISMS）：日本医療企画 2010 年 10 月
[10]プライバシーマーク認定指針第 3 版：MEDIS-DC 2011 年 1 月[11]医療情報システムの安全管理に関するガイドライン V4.1：厚生労働省 2010 年 2
月

39

第４章

クラウドガイドラインと IHE

４．１ はじめに
本稿では、「クラウドサービス利用のための情報セキュリティマネージメントガイドライン(経済産業省 2011.4)」(以下、“本ガイドライン”と略す)の記載を IHE XDS の利用面に則して解釈する。
先だって、近年のクラウド利用にあたって懸念される事項を報じた内容を参考として列挙する。
（１）クラウド提供者によるリスク開示(デジタル・フォレンジック・コミュニティ in Tokyo 2010 資料：ORACLE 社)
ロサンゼルス市議会の Google Apps 採用時の要望(2009.9.15)に、以下の 8 項目がある。
・ Google は ’GovCloud’ と 呼 ば れ る 新 し い 隔 離 さ れ た デ ー タ エ リ ア を 提 供 する。’GovCloud’は公的機関のみが利用できる。
・データは論理的、物理的に Google の一般のクラウドからは隔離される。
・データは休止中は暗号化され、読み取り不可能となる。
・データはアメリカ国内(大陸)のみに存在し、適切なバックグランドチェックと許可を受けたアメリカ国民のみアクセスすることができる。
・データは多数の部分に分解され、各々が様々なサーバに蓄積される。データの一つ
或いは一部分が盗まれるか損なわれたとき、データは全体の暗号化された一部であるので、再生成する為のキーが存在せず安全であること。
・Google のハードを扱う管理者は、データセンターのごく一部にのみアクセスすることができ、すべてのサーバやデータ暗号化鍵にアクセスすることが出来ない。管理者はデータを閲覧したり、暗号化されたデータを複合して読める形式にすることが出来ないこと。
・カスタマーサービスと市の問題や要求に答える Google のスーパー管理者はデータを複合して可読形式にするツールと鍵を持っていなければならない。
・契約中において、Google は市に属するデータに対する情報公開要求に対して市が拒否権を持っていることに同意する。市が適切な行動をとれるようにデータに対するどんな要求や、セキュリティ上の欠陥も市に報告する。
（２）クラウド利用のリスク(2010.10 朝日新聞)2009 年 4 月に米国ダラスに所在するネットプロバイダのデータセンタの２フロア分の設備を FBI が「同社のユーザである或る企業を調べるため」押収した。間もなく「メールが見られない」「データにアクセスできない」影響が出た利用者は約 50 社に達した。
40

（３）米国の法規制(2010.10 朝日新聞)
米国政府は政府機関がクラウドを利用する場合は米国本土内のデータセンタを使うことを定め、尐なくとも他国の法律や捜査などの影響を受けない様にしている。GSA(連邦調達庁)2009.7（４）クラウドコンピューティングの法的リスク(デジタル・フォレンジック・コミュニティ in Tokyo 2010 資料：町村)・法的リスクの要因＝国境をまたいだ分散処理、サービスのボーダレス性：外国法(政府の民間データへの介入可能性)、外国法執行機関による捜索・差押え、裁判管轄権、証拠保全、知財権/著作権保護、個人情報保護法、有害情報対策・パブリック・クラウドにおけるディスク供用：差押え、クライアントのコントール限界・クラウド・プロバイダの倒産リスク＝事業継続性：倒産法の域外適用、倒産時の法的処理は契約では限界がある、ディスクの行方
上記の内容特に（４）を念頭に置くことで、本ガイドライの解釈が進むと思われる。
本ガイドラインは対象を医療機関に限定しているものではなく、一般的にクラウドを利用する組織に対しての情報セキュリティマネージメントをガイドしている。前提として JIS
Q 27001/JIS Q 27002 の ISMS(情報セキュリティマネージメント)実施を想定し、さらにクラウドを利用する際の管理策を追加している。
図４－１から図４－４までは、参考として本ガイドラインと対で公表の解説(経済産業省)から抜粋したものである。
以降の文内で【】内には本ガイドラインの記載箇所を示す。

41

図４－１ 概要

図４－２ 位置づけ42図４－３ 本ガイドラインの内容

図４－４ 実施事項のイメージ

43

４．２ 本ガイドラインと IHE の関連
医療機関の情報システムで、クラウドがとりわけ問題になるのは、診療記録の外部保存、
アプリケーション機能に ASP・SaaS を用いる場合に浮上してくる。
医療機関向けの情報システムのセキュリティに関しては、既に「医療情報システムの安全管理に関するガイドライン第 4.1 版」(厚生労働省 2010.2)が発行されている。
この中で、診療記録の民間業者への外部保存に当たっては、経済産業省「医療情報を受託管理する情報処理事業者向けガイドライン」(2008.3)と、さらに場合により総務
省「ASP・SaaS における情報セキュリティ対策ガイドライン」(2008.1)の遵守確認を条件として、認められている。このことは、システムに IHE を用いた場合でも例外なく適用される。
医療機関内にある診療情報の外部保管に関してはシステムに IHE を用いる・用いないに関わらず、一般論として上記の「安全管理に関するガイドライン」を遵守する必要がある。
IHE としての特有の事情が発生するのは、XDS、XDS-I の形態を用いる場合に、レジ
ストリ、場合によっては或るレポジトリが個々の医療機関の管理責任外に存在し、それがクラウド環境にある場合である。ここでは、XDS、XDS-I で構築された既存の XAD に加入する場合を想定する。診療録（レジストリに格納されているメタデータであっても個人の診療の事実を示す）を当該医療機関から外部に提供し、保管を始め種々の機能を医療機関の外部事業者から提供を受けることに対して、クラウド事業者が XAD の運用に関与する際に、考慮しなければならない事項には、直接の外部保管委託との差はないと思われるので、本稿では区別せずに議論する。医療機関がクラウドを用いてXAD を運営する場合も同様である。
医療情報を直接の対象とする上記３つのガイドラインでの幾つかの主要請事項が本ガイドラインでどのように記載されているかを、以下の項で列挙する。
４．３ 既存のガイドラインとの関係
当然ながら上記３つの診療録を対象にしたガイドラインの記載が本ガイドラインに優先するので、本ガイドラインでは「望ましい」の記載がされていても、医療機関では「せねばならない」と読替える必要が各所ある。
「ASP・SaaS における情報セキュリティ対策ガイドライン」(総務省)が、本ガイドラインと近い領域を対象にしているので、本ガイドラインを補完的に使用することが良いと思われる。安全性・信頼性の確保が重要であり、確認を怠ると、問題があること自体が把握できずに管理責任を果たせない可能性がある。「ASP・SaaS における情報セキュリティ
対策ガイドライン」に沿って内容の確認を行う必要がある。
「医療情報を受託管理する情報処理事業者向けガイドライン」(経済産業省)に従っ
44

て、クラウド事業者のデータセンタを確認することが必要である。
「安全管理に関するガイドライン」(厚生労働省)での「4 電子的な医療情報を扱う際の責任のあり方」と「８ 診療録及び診療諸記録を外部に保管する際の基準」が主な関連箇所である。
本ガイドラインでは、各所に分散されているが、通信上の管理策、情報の管理責任、
データの所在管理、法的責任について、以下に記載個所から抜粋して評価を例示する。
４．３．１ 通信上の管理策
本ガイドラインでは、【10.8.1 情報交換の方針及び手段】「通信経路が暗号化できず、データの改ざんチェッ
ク機能も備えていない機能がある可能性に留意することが望ましい」、【12.3 暗号による管理策】「ネットワーク経路が暗号化されていることを確認することが望
ましい」
とある。
このケースへの対策は「安全管理に関するガイドライン 6.11」では必須事項である。
ネットワーク上での保護策が無い状態では利用不可になる。
４．３．２

情報の管理責任本ガイドラインでは、【6.1.3 情報セキュリティ責任の割当て】「情報セキュリティに関する全体の責任はクラウド利用者に残ったままである」とある。
これは「安全管理に関するガイドライン」での指摘と同一である。業者の監督責任は利用者にある。
「安全管理ガイドライン 8.1.2」にある事業者選定のガイドに従って、クラウド事業者のセキュリティポリシーの確認や、資格条件を確認することが必要である。
４．３．３ データの所在管理
本ガイドラインでは、【6.1.5 秘密保持契約】「データの所在などをクラウド利用者が特定することは技術的に難しい」、【9.2.7 資産の移動】「事前にクラウド利用者の許可なく、データの物理的な所在が移動される可能性があることに留意することが望ましい」、【付属書 A（参考）クラウドサービス利用にかかわるリスク】「データセンターの所在
様々な国や場所にデータセンターが設置されることで、クラウド利用者の視点ではデー45

タセンターに従事する従業者の経験やモラルなどによる情報の取扱いの差が懸念事
項として挙げられている。様々な国のネットワークの接続性などに伴って、サービスの質などの差による影響が出る可能性が考えられる。また、現地の法執行機関による情報の差押えの懸念も発生する。そのため、クラウド利用者は、あらかじめデータセンタ
ーの所在地の法規の適用にかかわる問題を認識してリスクを 受容するかの検討を要
する。」
がある。
医療機関は患者に対して記録の保管が外部ならばその旨を開示する必要があり(「安全管理ガイドライン 8.1.3」)、無断でデータ保管地域を移動させることは安易に許容されていないと解釈すべきである。
データ所在地について、クラウド事業者との契約等で明確にする必要がある。
４．３．４ 法的責任
本ガイドラインでは、【15.1 法的要求事項の順守】「法律の定める要求事項は、国ごとに異なっており、また、一つの国で作成され別の国へ伝送される情報（すなわち、国境を越えたデータの流れ）についても異なる場合がある。」、【15.1.1 適用法令の識別】「クラウド利用者は、クラウドサービスの利用契約に定められた準拠法と裁判管轄を確認し、文書化することが望ましい。クラウド利用者は、クラウド事業者が適用を受ける法令を調査し、文書化することが望ましい。---クラウド事業者
が事業を行う国の法律や業界団体の慣習などについても洗い出し、検討することが望ましい。―――。外国法人でも日本国内において事業を行う限り、原則として国内法の適用を受け、逆に日本法人でも外国で事業を行う限り、外国法の適用を受けることがある。―――データセンターが国内にあっても外国で事業を営む企業は、その国の捜査
機関の捜査を受け、我が国のサーバ内の情報が差し押さえられることもある。」、【15.1.3 組織の記録の保護】「他国のクラウド事業者では、特定国内における法律に対応できないクラウド事業者がある可能性もある。そのため、―――記録の保管が適切に行うことができるクラウド事業者を選択するか、自ら記録を保管する体制を構築することが望ましい」などがある。
元来、診療録は日本国内法で作成・保管が定められたものであり、その保管場所は「日本国内法の適用箇所」(総務省のガイドライン)と定めらており、日本法人・外国法人に関わり無く国内法の適用箇所に保管することを遵守しなければならない。
[参考文献][1] 厚生労働省「医療情報システムの安全管理に関するガイドライン第 4.1 版」2010.2
46

[2] 経済産業省「医療情報を受託管理する情報処理事業者向けガイドライン」2008.3[3] 総務省「ASP・SaaS における情報セキュリティ対策ガイドライン」2008.1[4] (財)日本情報処理開発協会(JIPDEC)「医療機関向け ISMS ユーザーズガイド(改)」2008.547

第５章

最新の IHE ソリューションによる広域の連携システムの構築可能性について
５．１ はじめに地域医療連携が進んでいくと、糖尿病のドメイン（XAD）、脳卒中のドメイン、がん治療のドメイン、循環器のドメインなどの多種類のドメインが増えていくことは容易に想定できる。症例ごとにドメインが形成されていくと、参加する医療機関はその都度、リポジトリを用意し、ドメイン参加手続きが必要である。また各ドメインがばらばらに存在することで運用のコストも増加する。もし、中央のレジストリだけ対応の種類を増やすことができればドメイン運用のコストを抑えられる可能性も出てくる。一方では、疾患ごとに、XADのポリシーは異なる可能性が高く、参加する医療機関のグループも異なることになり、ひとつにできたとしても、複雑な運用になることが予想される。
IHE で は 、 コ ミ ュ ニ テ ィ 間 の ア ク セ ス の た め の 統 合 プ ロ フ ァ イ ル （ XCA （ Cross
Communication Access））がすでに用意されており、コミュニティを超えた運用の道が示されている。ここでは、XCA をどのように用いて実際の医療連携が可能かを検討してみる。
５．２ Cross Community Access の概要
XCA 統合プロファイルは、IHE IT Infrastructure Technical Framework

Supplement

Cross Community Access XCA Draft for Trial Implementation （2010 年 12 月） に記述されているものである。
この統合プロファイルは、コミュニティ(XDS アフィニティドメイン(XAD)とも呼ばれる)間
でドキュメントを共有するための手段を提供する。Document Consumer(共有情報の利用者)からは、コミュニティを超えてドキュメントを利用可能となる。コミュニティとコミュニ
ティを連携するのは、Initiating Gateway（開始ゲートウェイ）と Responding Gateway(応答ゲートウェイ)の２つのアクタである。２つのアクタが各コミュニティのゲートウェイとして、様々な関連コミュニティに問い合わせを発したり、結果を受信したりする仕組みである。
各コミュニティには homeCommunityId（コミュニティ ID）が付与されている以外、内部の構造について制限(あるいは規程)はないことになっている。即ち各コミュニティは XDSの構造（XAD）をもたなくても２つのアクタがゲートウェイとして機能すればよい。典型例
を図５－１に示す。ただし、この場合は、２つのコミュニティはいずれも XDS の構造をも
っている。

48

コミュニティA

コミュニティB
患者ID管理

医療機関C
長期診療

所在管理

患者ID管理所在管理

所在情報の登録

情報
の検索
共有情報
の保管

医療機関D
診療所など
共有情報
の保管

共有情
医療機関B
報の保
急性期診療
管
(入院)

医療機関A
初期治療、診療(救急)応答
ゲートウェイ開始
ゲートウェイ

共有情報の読み出し

所在の問い合わせ（Retrieve Document Set)

（Registry Stored Query)●●●●●●●●●●●●●●●●●●●●●●
A病院 ・・・・・・・・・
B病院 ●●●●●●
C病院 △△△△△

図５－１ コミュニティ間連携の構成（XDS 間）
Document Consumer から問い合わせのため Document Registry（Initiating Gateway とグループ化実装が可能）に Registry Stored query(所在の問い合わせ)トランザクション
を出し、Initiating Gateway に対して Retrieve Document Set でドキュメントセットを取り出す。Initiating Gateway はコミュニティの内部アクタを代表し、コミュニティを出て行く全てのトランザクションを開始するアクタである。Document Consumer から Registry Stored
Query と Retrieve Document Set(共有情報の読み出し)を受信し、自分のコミュニティ内の Document Registry(レジストリ)と Document Repository(リポジトリ)にトランザクションを伝え、Responding Gateway に接続して、Gross Gateway Query と Cross Gateway
Retrieve を送ることにより他のコミュニティにトランザクションを伝達する機能をもつ。
Responding Gateway は、コミュニティに入ってくる全てのトランザクションの唯一の接続
ポイ ントである 。入っ てくる トランザクショ ンをローカルア クタ（ Document Registry,
Repository）に伝達する。
図５－２は、XDS 型ではないコミュニティとの連携の例である。この場合、コミュニティ
B からみた相手方のコミュニティ A の内部は知らなくても、Responding Gateway、
Initiating Gateway が対応してくれれば可能である。

49

コミュニティA

コミュニティB
患者ID管理
所在管理

医療機関
D
診療所な
ど

応答
ゲートウェイ開始
ゲートウェイ

共有情報の読み出し

所在の問い合わせ（Retrieve Document Set)

（Registry Stored Query)●●●●●●●●●●●●●●●●●●●●●●
A病院 ・・・・・・・・・
B病院 ●●●●●●
C病院 △△△△△

図５－２ コミュニティ間連携の構成（XDS ではないコミュニティを想定）
５．３

コミュニティ間の画像情報連携（XCA-I）

2011 年になって、XCA-I（Cross-Community Access for Imaging)という画像ドキュメント
専用のコミュニティ間連携のプロファイルが発表された （IHE Radiology Technical
Framework Supplement :Cross-Community Access for Imaging（XCA-I） Draft for
Public Comment）。現時点ではドラフト段階であるが、XDS-I で運用されているコミュニ
ティ間の連携を目的としたものである。プロファイルでは、医療機関間の共有から患者の PHR までが対象とされている。
ユースケースとして、地理的に広がった地域で多くのコミュニティが立ち上がっていることが想定されている。それぞれのコミュニティは、XDS のインフラをもっており、レポートと画像のマニフェストを共有している。ドメインは、共通の患者 ID とコード化された用語をもっている。この中の２つのコミュニティが救急患者対応についてドキュメント共有を行うこととなった。ある患者が自ら登録されているドメインと異なったドメインの医療機関で救急治療を受ける。画像検査をオーダしようとした医師は院内の PACS にアクセスする。すでに行った画像検査を取得するためである。ここでは院内 PACS が Imaging
Document Consumer として自動的に自らの登録コミュニティとさらに連携している別のコミュニティへ検索を行う。XDS.b の Registry Stored Query トランザクションを Initiating
Gateway に出す。Initiating Gateway は、自らのコミュニティのレジストリへ問い合わせると同時に、別のコミュニティの Responding Gateway に問い合わせる。院内 PACS は
Imaging Document Consumer として同じコミュニティの医療機関の Imaging Document
Source にアクセスする。他のコミュニティの画像は、Initiating Gateway が Responding
Gateway アクセスすることで取得する。

50

開始コミュニティ

応答コミュニティ

Initiating Community

Responding Community

ドキュメントリポジトリ
XDS.b Document
Repository
ドキュメントの読み出
し↑ Retrieve
Document Set

ドキュメントの問い合わせ↑ Registry Stored
Query [ITI-18][ITI-43]

ドキュメント
利用者
XDS.b Document
Consumer

画像ドキュメント
利用者
Imaging Document
Consumer

ドキュメントの問い合わせRegistry Stored Query[ITI-18]→

ドキュメントの読み出
しRetrieve Document
Set [ITI-43]→

画像ドキュメントの読み出し
Retrieve Image Document Set[RAD-69]→

開始
ゲートウェイ
XCA Initiating
Gateway開始
画像ゲートウェイ
Initiating
Imaging Gateway

ドキュメントリポジトリ
XDS.b Document
Repository

ドキュメントレジストリ
XDS.b Document
Registry

ドキュメントレジストリ
XDS.b Document
Registry
ゲートウェイ間問
い合わせCross
Gateway Query[ITI-38]→
ゲートウェイ間読み
出しCross Gateway
Retrieve[ITI-39]→

ゲートウェイ間画
像ドキュメント読
み出し

ドキュメントの読み出
しドキュメントの問い合わせ↑ Registry Stored
Query [ITI-18]↑ Retrieve
Document Set[ITI-43]

応答
ゲートウェイ
XCA Responding
Gateway応答
画像ゲートウェイ
Responding
Imaging Gateway

画像ドキュメントの読み出し
Retrieve Image Document Set[RAD-69]→

Cross Gateway
Retrieve Imaging
Document
Set[RAD-75]→

画像ドキュメント
ソース
Imaging Document
Source

図５－３ XCA-I 統合プロファイル
以上のような形での画像共有を行うことにより、救急で倒れたようなケースにおいても、各医療機関からの画像情報を瞬時に取得し、適切な画像診断と治療の対応が可能となる。
このように IHE XCA-I を用いることにより、従来のコミュニティ内のみでの共有を容易に拡張することができる。画像データの標準化は他の医療情報より普及しており、コミュニティ間での画像の共有実現に期待ができる。この場合は症例ごとの共有という考え方を超えて、画像情報の連携というくくりでの統合になる。画像の連携については、
すでに PDI を用いた、フリーアクセスの連携が普及しつつあり、それに伴う問題も浮かび上がっている。オンラインの連携においてもその経験を踏まえたネットワーク連携の構築が必要と考えられる。たとえば、新しい SOP データを古い PACS ビューアが取り扱えないことなども想定され、PDI の拡張版（IHE Radiology Technical Framework :Extensions to the Portable Data for Imaging(PDI) ）にあるような SOP を古いバージョンに(とりあえず表示できるように)書き換える処理も必要となる。
５．４ PHR への展開
医療機関間の連携とは別に、個人が自分の情報を管理し、いつでもアクセスできるという PHR への展開例として RSNA2010 においてデモンストレーションされた個人への画像
情報サービスの例（Patient Controlled Image Sharing）を図５－４に掲げる。

51

自宅

患者ID
ソース

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

ドキュメント/画像リポジトリ
ドキュメント/画像
利用者
ドキュメントソース

画像ドキュメント
ソース
ソース

Patient Controlled Image Sharing

図５－４ XDS-I による PHR の例
図５－４は、各医療機関、画像センタがドキュメントソース（Document Source）を Edge
Server に共有情報として提供し、その内容を Clearinghouse（PHR のサービスセンタ）の画像ドキュメントリポジトリ（Image Document Repository）に提供する。患者は自宅の PCの ド キ ュ メ ン ト 利 用 者 （ Document Consumer ） と 画 像 ド キ ュ メ ン ト 利 用 者 （ Image
Document Consumer）から Clearinghouse にあるレジストリを参照し、各医療機関で受けた検査の情報をリポジトリ、ドキュメントソースから取り出し、参照することができる。
IHE XDS-I がこの基盤を支えている形となっている。
このシステムが稼働することにより、従来 PDI 統合プロファイルを利用した CD などで持ち運んでいた情報をネットワーク経由で即座に入手し、担当する医師が参照することも可能となる。
５．５ ガイドラインとコミュニティ間連携
コミュニティ間の連携によって外部保存を行うことを想定すると、この場合ネットワークに参加している医療機関が不特定多数となるため外部保存が可能な要件は満たされないという判断となる。例えば、別のコミュニティに属する医療機関に救急で運び込まれるような場合、必要な医療情報を患者の通常属しているコミュニティにアクセスして、呼び出すことができれば、診療に大変に寄与することになる。一方、研究目的でコミュニ
ティ間の連携で患者の情報を集めるケースであれば、患者本人の同意を前提とした運52

用が必要である。コミュニティを超えてデータを受け渡すことは、第 3 者提供となるため、患者の了解が得られていること（オプトイン）が必要となる。実際にコミュニティ連携している状態は、不特定多数の病院が参加する状況が考えられるので、そのことを患者にどう説明するのかが問題となる。
連携にあたっては、コミュニティ内のセキュリティ対策（Initiating Gateway までの）が十分であることについて、連携先のコミュニティが了解している必要がある。さらに、
Initiating Gateway と Responding Gateway の間の責任分界に関する対策ができていることも必須である。
今後、このような問題にどう対応していくのか継続した議論が必要となる。
[参考文献][1] IHE IT Infrastructure Technical Framework Supplement Cross Community
Access XCA Draft for Trial Implementation 2010 年 12 月
[2] IHE Radiology Technical Framework Supplement :Cross-Community Access for
Imaging（XCA-I） Draft for Public Comment 2011 年 5 月[3] IHE Radiology Technical Framework : Extensions to the Portable Data for
Imaging(PDI) Integration Profile 2009年7月

53

第６章

直接医療機関をつなぐ安全な連携についての IHE 統合プロファイル

６．１ Point-to-Point の地域連携の必要性・誕生の背景
近年地域連携に代表される複数施設間の情報連携の必要度が高まっており、実際に稼働するシステムも増加している。複数施設間の情報連携の連携方法を考えた時に、必ずしも患者情報を常に参照可能な形で共有する必要があるわけではないことがわかる。例えば、紹介状や患者退院サマリのように、紹介元－紹介先と一方通行に情報が伝わればよい場合が考えられる。また、基盤インフラが確立できず情報共有の基盤となる XDS のレジストリ・リポジトリが用意できない環境も考えられる。このような場合でも安全に施設間情報連携を行うことができるよう IHE-ITI 領域では XDR(Cross-Enterprise
Document Reliable Interchange)を提案している。
６．２
概要

IHE が提案する XDR"Cross-Enterprise Document Reliable Interchange"① XDR 統合プロファイルのスコープ・検討範囲
 XDR(Cross-Enterprise Document Reliable Interchange)は、標準規格を基にして、医療機関の間で、信頼に基づいた point-to-point（１：１）ネットワーク・コミュニケーションを用いて、Document の交換を実現する。本統合プロファイルも、電子健
康記録（EHRs）、個人の健康記録（PHRs）と他のヘルスケア IT システムの間でよ







り良い interoperability の提供に役立つ。これは、情報共有基盤（Repository とRegistry）が必要でない場面において役に立つ、IHE ITI XDS 統合プロファイルの補足（補遺）である。
情報共有の方法としては、XDS(Cross-Enterprise Document Sharing)のような、「publish and pull」型のメカニズムが提供されており、本統合プロファイル XDR は送信元から送信先へ文書を送信する「Push」型コミュニケーションを実現している。
現在の XDR 統合プロファイルは、特定の患者に関する文書およびそのメタデー
タを、HTTP/ SOAP を利用したセキュアな通信方法での交換を提案している。メ
タデータと通信方法については XDS と同様である。
2010 年夏に更新された XDR 統合プロファイルでは、XDS.b に完全に対応しようとしている。通信（トランザクション）では、XDS.b と同じ transaction「Provide andRegister Document Set-b」を再利用する仕様となっている。

54

図６－１ XDS と XDR の利用するトランザクション② XDR 統合プロファイルのユースケース
 UseCase1：医師 Primary 先生は、担当患者ロビンソンさんを、消化管専門医に紹介します。消化管専門医の Gastro 医師のクリニックとは XDS や XDS-MS を利用できる環境にありません。また Gastro 医師と Primary 医師は、情報を共有できるほど（おなじ Affinity Domain に所属するほど）信頼関係はありません。このような場合に、XDR 統合プロファイルは、患者ロビンソン氏の照会情報の交換のために役立ちます。このようなケースでは XDR の方が XDS より利用しやすいです。XDR
は、Gastro 先生から Primary 先生への文書提供にも適切です



UseCase2: メイベルさんは、長期療養のために、病院から彼女の retirement
home に移動します。 XDR を利用してメイベルの情報は、彼女担当の主治医と看護師によって病院から長期療養所の EHR に移管されます。
UseCase3:スタンリーさんの最近の MRI の結果が通常とは異なる状態だったので、
主 治医は、がん専門 医に相談し よう と思い ます。当院の遠隔診断ができる
Affinity Domain には適当な医療機関がありません。XDR はこの代わりに利用することができます。
UseCase4: Sweettooth 夫人は成人糖尿病と診断されました。彼女が受診した医療機関は、文書を共有できるような仕組み（XDS)が実現できていませんでした。
XDS が実現されるまで、担当医療機関は XDR を用いてピア・ツー・ピアで彼女の情報を交換し合う必要があります③ アクタとトランザクション
55

XDR のアクタとトランザクションを以下に示す。

15.2.2 Basic Patient Privacy Enforcement Option
上記のトランザクションを実現するために利用している標準規格を以下に示す。
表．XDR が利用している標準規格一覧④ プロセスフロー
XDR 統合プロファイルは以下のとおりである。

文書（ドキュメント）の送信元(Source)から受診先（Recipient）へ XDS と同じトランザクショ
ンを利用して文書を送信する。データ識別のために生成するメタデータについても
XDS と同様である。
⑤ XDS"Cross-Enterprise Document Sharing"との違い
56

施設間連携に有用と考えられる３つの統合プロファイルは以下のとおりである。
XDS: Cross-Enterprise Document Sharing 文書共有
XDR: Cross-Enterprise Document Reliable Interchange １：１の文書交換
XDM: Cross-Enterprise Document Media Interchange 媒体メディアを利用した
文書交換

先にも述べたが XDS と XDR/XDM とのもっとも大きな違いは「共有」を行うかどうかである。共有を行うためには文書所在を管理するレジストリや文書本体を保管するリポジトリ
環境を用意する必要があるが、一方通行の XDR や XDM ではその必要がない。このことから、XDS を導入するよりも運用面、技術面ともに導入のハードルは低くなると考える。
６．３ 事例紹介：放射線医学総合研究所が必要とする施設間連携機能のユース
ケース
放医研では以下のような３つの施設間情報連携のユースケースを検討している。
⑥ UseCase1: 重粒子治療の治療依頼・フォローアップ連携
 粒子線治療の依頼時や治療終了時の病歴データを依頼元やフォローアップ先などと連携する。
 対象データは、画像データ、紹介状、診断書、診療情報提供書、治療サマリ、照射録 など⑦ UseCase2:重粒子治療のセカンド・オピニオン
 患者は、近医または中核病院で検査を行う。
 その画像を提携している連携システムに登録する。
57



画像を用いて粒子線治療の可否についてコンサルテーション依頼




⑧

依頼された施設は、連携システムから画像の存在場所を調べ、画像を取得
コンサルト結果を連携システムに登録
患者は、近医または中核病院で結果を連携システムから参照
UseCase3:粒子線治療の多施設共同研究

粒子線治療（陽子線・炭素線）の症例情報と予後情報を収集。
対象臓器：前立腺から開始し、他の部位へも拡張。
対象データ：症例登録情報（年齢、腫瘍情報、放射線治療情報など）、フォローア
ップ情報（再発有無、転移有無、転帰情報など）、QOL 情報

図６－３ 放医研の施設間連携のユースケース
放医研では、今回上記 UseCase3 の多施設共同研究の症例収集の事例を、XDR を用いて実現することとした。２０１０年３月現在、プロトタイプ版を作成中である。
６．４ 導入事例：粒子線治療の多施設共同研究症例情報収集システム① 登録データのイメージを以下に示す。

58

図６－４ 多施設共同研究症例情報収集データイメージ② XDR 利用にともない技術的に検討している点は以下のとおり。
 データ登録時のメタデータの設計 （患者番号、データ発生時刻の定義、データ有
効期限の定義 、データ識別子 、等） 同時に利用する統合プロファイル”ATNA”（監査証跡ログを出力するイベントの検討）

ユーザインタフェース（データ送信元／送信先の画面設計 、システム管理者用機
能の整理 ）[参考文献][1] IHE IT Infrastructure (ITI) Technical Framework Supplement 2009-2010
Cross-Enterprise Document Reliable Interchange (XDR)
Trial Implementation
Supplement Version – Release 4.0 August 10, 2009[2] IHE IT Infrastructure Technical Framework Supplement 2006-2007
Cross-Enterprise Document Reliable Interchange (XDR)
Trial Implementation
Version August 15, 200659

本ハンドブックは、厚生労働省事業により支援を受けて作成しました。
転載について、引用にあたっては出典を明確にしてください。
サンプルについての使用は自由です。

2011 年７月 20 日発行「地域医療連携情報システム構築ハンドブック 2011」 別冊
IHE-XDS をめぐる最近の動向――日米の政策、クラウド技術、広域な連携について――
著作権、発行元： 日本 PACS 研究会・日本 IHE 協会

60