Comments
Description
Transcript
報告書PDF版 - 東京大学大学院医学系研究科・医学部
1. はじめに .................................................................. 1 2. 概要 ........................................................................ 1 3. 背景 ........................................................................ 3 3.1. 日 本 の 医 療 機 関 に お け る IT 化 の 現 状 ................................. 3 3.1.1. オーダリングシステムと電子カルテ.................................................. 4 3.2. レ セ プ ト の 電 子 化 ........................................................... 6 3.2.1. 病院の IT 化 ....................................................................................... 8 3.2.2. 診療所の IT 化.................................................................................... 9 3.2.3. 調剤薬局の IT 化 .............................................................................. 12 3.3. IT に よ る 医 療 機 関 情 報 連 携 の 現 状 .................................... 12 3.3.1. 医療機関情報連携のモデル .............................................................. 12 3.3.2. 国内の IT による地域医療情報連携プロジェクト............................ 15 3.3.3. PHR と EHR.................................................................................... 16 3.4. IT に よ る 救 急 医 療 に お け る 情 報 活 用 の 状 況 ........................ 17 3.5. 調 剤 情 報 の 病 薬 連 携 の 必 要 性 ........................................... 18 3.6. 医 療 IT 政 策 と 現 状 と の 関 連 ............................................ 19 3.7. 診 療 情 報 連 携 に お け る セ キ ュ リ テ ィ ー と プ ラ イ バ シ ー 保 護 .... 22 3.7.1. 医療情報システムの安全管理のガイドライン ................................. 22 3.7.2. 医療における個人情報保護法 .......................................................... 27 3.8. 諸 外 国 の 医 療 IT 化 の 状 況 と 比 較 ...................................... 28 3.9. 医 療 に お け る 高 度 情 報 連 携 の 必 要 性 と 課 題 ......................... 30 3.9.1. 高度な情報連携の必要性.................................................................. 30 1 3.9.2. 医療機関における情報連携の課題 ................................................... 31 4. 目的 ...................................................................... 35 5. 具体的目標 ............................................................. 36 6. 実証実験の構成、方法および実施体制 ......................... 37 6.1. 地 域 医 療 情 報 連 携 ハ ブ の 考 え 方 ........................................ 37 6.2. 地 域 医 療 情 報 連 携 ハ ブ の 機 能 ........................................... 41 6.3. 地 域 医 療 情 報 連 携 ハ ブ の 実 装 方 法 ..................................... 45 6.3.1. ハードウェア構成 ............................................................................ 45 6.3.2. 接続回線の暗号化 ............................................................................ 48 6.3.3. 診療情報連携向けアプリケーション................................................ 49 6.3.4. データベース.................................................................................... 66 6.3.5. 患者向けアプリケーション .............................................................. 67 6.3.6. 公開鍵ディレクトリサービス .......................................................... 71 6.3.7. 調剤実施情報連携向けアプリケーション ........................................ 75 6.3.8. 実行環境 ........................................................................................... 77 6.3.9. 暗号化ツール.................................................................................... 77 6.3.10. 調剤実施情報集配信 Web サーバ ................................................... 80 6.4. セ キ ュ リ テ ィ ー に 関 す る 方 針 ........................................... 82 6.4.1. 利用者の識別及び認証 ..................................................................... 82 6.4.2. 情報の区分管理とアクセス権限の管理 ............................................ 82 6.4.3. アクセスの記録（アクセスログ） ................................................... 83 6.4.4. 不正ソフトウェア対策 ..................................................................... 83 6.4.5. ネットワーク上からの不正アクセス................................................ 83 6.4.6. 「盗聴」の危険性に対する対応 ....................................................... 84 6.4.7. 「改ざん」の危険性への対応 .......................................................... 84 6.4.8. 「なりすまし」の危険性への対応 ................................................... 85 2 6.5. 地 域 医 療 情 報 連 携 ハ ブ の 運 用 ル ー ル .................................. 85 6.6. 実 施 体 制 ...................................................................... 86 7. 実験の結果 ............................................................. 88 7.1. 診 療 所 と 情 報 連 携 実 験 .................................................... 88 7.2. 調 剤 薬 局 と の 情 報 連 携 実 験 .............................................. 90 8. 考察 ...................................................................... 92 8.1. 地 域 医 療 情 報 連 携 ハ ブ の ル ー ル お よ び 運 用 条 件 に つ い て ....... 92 8.1.1. 医療機関とハブとの間の安全確実な情報転送の確立....................... 92 8.1.2. 医療機関側のセキュリティーポリシーとの整合性 .......................... 94 8.1.3. ハブでの情報転送の進捗状況の管理................................................ 95 8.1.4. 診療所との情報連携 ......................................................................... 96 8.1.5. 調剤薬局との情報連携 ..................................................................... 96 8.1.6. 救急患者のための情報の取り扱い ................................................... 97 8.1.7. セキュリティー確保に関わる総合的な課題 ..................................... 98 8.2. 公 開 鍵 デ ィ レ ク ト リ サ ー ビ ス に 関 す る ル ー ル と 必 要 条 件 ..... 100 8.3. 患 者 に よ る 情 報 コ ン ト ロ ー ル の あ り 方 ............................. 101 9. 提言に向けて ......................................................... 103 9.1. 地 域 医 療 情 報 連 携 ハ ブ セ ン タ ー 実 現 に 向 け た 制 度 整 備 ........ 103 9.1.1. 診療情報電子的配送サービス ........................................................ 103 9.1.2. 全機関の公開鍵証明発行・登録・検索サービス............................ 104 9.2. ガ イ ド ラ イ ン の 整 備 に つ い て ......................................... 105 3 9.2.1. 診療情報の電子的到達確認に関するガイドライン ........................ 105 9.2.2. 診療情報電子的配送サービスと医療機関との責任分界 ................. 106 9.2.3. 個人情報保護ガイドラインにおける救急時診療情報の取扱い ...... 107 9.3. 医 療 情 報 シ ス テ ム 業 界 に お け る 新 た な 対 応 の 必 要 性 ........... 108 9.3.1. 組織型の公開鍵証明書の必要性 ..................................................... 108 9.4. 国 際 展 開 の 可 能 性 ........................................................ 109 10. まとめ ................................................................ 110 11. 参考資料 .............................................................. 111 11.1. 参 加 医 療 機 関 ............................................................ 111 11.2. シ ス テ ム マ ニ ュ ア ル ................................................... 111 1 [注] 本報告書に使用されている図表は、特に記載がない限りすべて本報告書用に独 自に作成されたものである。 4 1. はじめに ICT は近年、我が国経済を中長期的な成長軌道に乗せるための重要な 要素として期待されている。e-Japan 戦略および i-Japan 戦略では、医 療における諸問題のいくつかの解決方策のひとつとして ICT を利活用す る方向性が示されている。実際、診療所や病院では電子カルテやオーダ リングシステムの導入が始まっており、医療機関の ICT 化のメリットの ひとつに、医療機関相互に診療上必要となる情報をやりとりすることに よって、患者が他の医療機関で受けた診療の内容を別の医療機関が迅速 かつ正確に把握できることが挙げられている。こうしたメリットは医療 界でも一定程度認識され、実現のための個々の技術要素は進歩しており、 これらの情報連携を実現するための種々の法的整備や技術的標準化の整 備と普及方策が各方面でこれまでにも図られてきた。しかし、救急診療 時のような非常時や調剤薬局との情報連携のような事前にデータ交換相 手の機関を特定しない状況でのデータ交換などの具体的な方策、それを 実現するサービス、患者の同意の取り方やデータの送受信ルールなど、 実現のためのさまざまなルールとサービスモデルが確立していない。そ のため、既に電子カルテ等を導入し ICT 化を実現した医療機関において も、他の医療機関との必要な診療情報のやりとりはほとんど行われてい ないのが実情である。本報告書では、平成 21 年度に総務省が実施した 「ICT 利活用ルール整備促進事業（サイバー特区）」に基づく「地域医療 高度情報連携サービス実現推進に向けた実証実験（平成 21 年度 1043-0019）」の成果を報告し、こうした問題の解決の一助としたい。 2. 概要 診療所や病院では電子カルテやオーダリングシステムの導入が始まっ 1 ているが、その導入率は 15 25％程度である。医療機関の ICT 化のメリ ットのひとつに、医療機関相互に診療上必要となる情報をやりとりする ことによって、患者が他の医療機関で受けた診療の内容を別の医療機関 が迅速かつ正確に把握できることが挙げられる。これは救急医療時には 特に重要な役割を果たす。 こうした状況のもとで、これらの情報連携を実現するための種々の法 的整備や技術的標準化の整備と普及が各方面でこれまでにも図られてお り、一定の前進は見られる。しかし、救急診療時のような非常時や調剤 薬局との情報連携のような事前にデータ交換相手の機関を特定しない状 況でのデータ交換などの具体的な方策、それを実現するサービス、患者 の同意の取り方やデータの送受信ルールなど、実現のためのさまざまな 取り決め（ルール）とサービスモデルが確立していない。 こうした状況を鑑み本実証実験では、診療情報を相互に送信または受 信する必要のある医療機関等（診療所、病院、調剤薬局、検査センター、 健診機関など）がスムーズかつ安全にそれを実現できるようにするため、 医療機関、調剤薬局などの医療関連機関の相互間で、安全、確実かつ信 頼のおける形態で簡単に診療情報を配送できる地域医療情報ハブ構想を 提起し、そのシステム構築を行い、運用実験を 1 病院、5 診療所、7 調剤 薬局が参画して実施した。 その結果、電子診療情報配送サービスを事業者が実施できる制度が整 備され、それを実施するために全医療機関、全調剤薬局を対象として制 度的に機関の電子アドレス情報と公開鍵証明情報が登録され、電子情報 を送信したい医療機関や調剤薬局が公開鍵ディレクトリサービスにより その情報を検索・取得して、電子診療情報を確実かつ安全に相手医療機 関に送信できることが必要であると考えられた。 また、医療機関等の開設・廃止・異動に関する情報を制度的に一元収 集し、電子情報配送サービス提供者としての条件を明確にし、医療機関 と電子情報配送サービス提供者との責任分界を明示した契約書の在り方、 2 組織単位の公開鍵証明発行のルール、救急診療時に備えた重要な診療情 報の事前預託ルールの整備、特にその際の患者の同意の取り方と範囲に ついて今後検討しガイドライン等を整備していくことが必要であると考 えられた。 3. 背景 3.1. 日本の医療機関における IT 化の現状 医療における IT というと、診療報酬請求書（レセプト）のコンピュー タによる作成、電子レセプト請求、オーダリングシステム、電子カルテ、 画像管理システム(PACS)など 1 医療機関内のデータ管理や処理のための システムの導入がその代表的なものであろう。さらに、地域の医療機関 同士で電子データにより診療情報をインターネット上で共有する地域医 療情報ネットや遠隔医療の一種であるテレパソロジーなども一部で試み られている。これらのシステムの違いについては後述するが、これら医 療情報システムのメリットはこれまで、診療データの効率的かつ正確な 管理や事務管理の効率化、診療データの共有による診療の質の向上や利 用の効率化、医療全体の事務コストの削減、国全体での医療の効率的な 分析、臨床研究のデータ収集と管理、などに大きく貢献するものであり、 国家的に推進していくことが必要であることが謳われてきた。実際、2001 年に厚生労働省は保健医療分野の情報化に向けてのグランドデザインを 策定し、その後も政府の IT 戦略本部のもとで策定される e-Japan 戦略や i-Japan 戦略をベースとした医療 IT 戦略が打ち出され、医療 IT 整備に向 けた種々の進展があったといえる。一方で、こうした 10 年近い推進計画 にもかかわらずその間に常に医療分野の IT 化は遅れていると指摘され、 あとで詳しく述べるように韓国のレセプトオンライン化 100％実施率に 3 対して、日本は医療機関数で 17%（2009.8 時点）、診療所での電子カル テ導入率は北欧や欧州先進国で 90％以上であるのに対して日本では 10% 程度であり、医療において IT が先進的に取り入れられているかと問われ れば、そうであるとは言い難い面がある。 3.1.1. オーダリングシステムと電子カルテ 医療機関における IT 化を論じる際に代表的な情報システムとして取り 上げられるのが、オーダリングシステムと電子カルテシステムである。 オーダリングシステムは日本では 1970 年代後半から一部の総合病院で 導入され始め、1980 年代に入り国立大学病院に順次普及、その後 400 床 以上の病院にも普及がするようになったもので、現在では 400 床未満の 病院でも導入する病院が増えつつある。オーダリングシステムは、病院 で医師がこれまで紙の伝票類に医療指示を記入して院内の他職種や部門 に依頼し、その結果を伝票で受け取っていた多くの情報を、コンピュー タにより処理するものである。たとえば処方箋の作成、検査指示伝票と 検査結果、処置や注射指示伝票などを伝票に記入して伝えるのではなく、 医師自身がコンピュータ端末に指示内容を入力して伝えるものであり、 情報発生源者である医師自身がコンピュータに入力することから発生源 入力システムとも呼ばれていた時期もある。オーダリングシステムが稼 働していない病院では、処方箋の内容、注射や処置（包帯交換や傷の縫 合など）の内容が会計計算のために必要最小限の情報しかコンピュータ に入力されていないことになり、また検査結果なども医師による指示情 報が入力されていないためコンピュータ化されないことが多い。そのた め、オーダリングシステムは医療機関、特に病院における IT 化の基盤と 言える。なおオーダリングシステムの病院での導入率は「病院の IT 化」 で詳述するが、200 床未満の病院での導入率が低く、医療機関同士での情 4 報連携を実現する上で大きな課題である。 電子カルテシステムは、オーダリングシステムがカバーしている「医 師が他職種や他部署に指示する医療行為の情報」だけでなく、医師自身 が実施する診療行為（診察、検査、患者とのやりとり）を記録する診療 録（いわゆるカルテ）の内容までもコンピュータに入力して管理するこ とにより、診療に関するほぼすべての記録をコンピュータ管理するもの である。この場合には、医師法、医療法をはじめとする多くの医療関連 法令に規定される診療に関する記録一切を電子カルテシステムで記録、 管理することになるため、いわゆる e-文書法とその関連法令にもとづく 一定の条件を満たした情報システムであることが求められ、同時に運用 ルールを明記した規定の作成と遵守が必要になる。従来、紙のカルテと して漠然と定義され管理されていた診療情報のなかには、その医療機関 が診療上の記録としてファイリングしていたものだけに留まらず、他院 からの診療情報提供書や手紙、診断書の写し、看護業務などを円滑に行 うためのチェックリスト、引き継ぎのためのサマリー、患者に渡した説 明書のコピー、患者署名のある同意書、などがあり、すべてを電子化す ることが運用上難しいものが多く含まれる。そのため、こうした診療上 発生した附帯的な情報については、電子化せず紙のままファイリングし たり、一括してスキャナにより入力したりしているケースも多く、その 運用ルールは明確に統一されていないのが現状である。 5 図 3．1 オーダリングシステムと電子カルテの構成例 3.2. レセプトの電子化 レセプトは、国民皆保険の医療制度を運営する日本の医療において、 医療機関が患者に提供した医療の報酬を保険者に請求するための請求書 であり、多くの医療機関では実施した医療行為の詳細な内容を請求書に 記載して医療行為ごとに決められた保険点数（1 点 10 円）から計算され る診療報酬額を請求し、出来高請求と呼ばれる制度で運用している。こ のスタイルの病院ではレセプトに、保険請求可能な医療行為の内容を示 すコードとその提供量が記録されており、レセプトデータから提供され た医療行為内容と量を知ることができる。一方、一部の急性期入院診療 を実施する病院では DPC とよばれる診断群分類にもとづいた包括診療報 酬請求を行っており、DPC レセプトでは、患者の診断群分類コードと入 院期間はわかるが、その間に実施された詳細な医療行為の内容と量は知 り得ない。いずれのレセプトにおいても、検査結果の詳細や院外調剤薬 6 局に出した処方箋の内容、手術や処置の詳細な実施内容は記載されず、 各医療行為と検査結果との対応や、医学的根拠は記録されないので、診 療情報の電子的記録としては不十分である。 レセプトコンピュータによる診療報酬請求書（レセプト）の作成は、 ここ数年急速に普及している。社会保険診療報酬支払基金で公表されて いる資料（http://www.ssk.or.jp/rezept/hukyu.html、 レセプト電算処 理システム年度別普及状況）によれば、平成 22 年度 2 月見込みで病院か ら提出されるレセプト件数の 99．6％がコンピュータにより作成されてお り、病院数で見ても 92.8％が電子レセプトによる請求を行っており、400 床未満の病院でも 92.2％が同様であることから、レセプト請求に関して は病床規模によらず電子レセプトがほぼ普及している。 診療所でのレセプト処理用コンピュータの使用状況を全国診療所を対 象として平成 17 年 10 月に実施された平成 17 年度厚生労働省医療施設静 態調査の結果をみると、一般診療所 66.1%、歯科診療所 57.7%となって いる。また、これを一般診療所の病床の有無別でみると、 「有床」では 79.1% となっており、2008 年 7 月に公表された民間企業シードプランニングに よる調査では診療所でのレセプトコンピュータ導入率は約 80％と発表さ れている。しかし、社会保険診療報酬支払基金の平成 22 年 1 月診療分レ セプトの内訳公表資料によれば、診療所 88,824 のうち手書きレセプトに よる提出は 10,182 箇所、11.5%となっており、これから逆算すると診療 所におけるレセプトコンピュータ導入率は 88.5%となる。診療所でコン ピュータを導入せず外部業者に委託してレセプトをコンピュータ作成し ているところもこの中には含まれていると考えられ、概ね診療所でのレ セプトコンピュータ導入率は 80％台の半ばであると推定される。前述の 資料によるレセプト件数にしめる電子レセプト割合で見ると診療所によ るレセプトの 67.3％がレセプトコンピュータで作成され、診療所数では 54．6％を占めている。またオンライン請求は診療所の 25.6％、件数にし て 32．2％となっている。 7 なお、調剤薬局のレセプトコンピュータ導入状況については、調剤薬 局の IT 化の項で説明する。 3.2.1. 病院の IT 化 日本の病院でのオーダリングシステムや電子カルテシステムの導入状 況については、さまざまな調査があり結果にも幅があるが、ここでは厚 労省により 3 年に 1 回実施されている医療施設静態調査の結果で見てみ ることにする。同調査は平成 8 年から 20 年の 10 月に全医療機関に対し て実施されており回収率は 100%である。病院に対する IT 関連の調査項 目の中に、オーダリングシステムと電子カルテシステム（平成 14 年から 開始）をそれぞれ導入しているかどうかを回答する質問項目がある。オ ーダリングシステムには検査オーダーだけのものからほぼ全種類をカバ ーするものまで混在していると思われるが通常、最低でも検体検査と処 方せん作成はカバーしていると考えられる。図 3.2 は平成 8 20 年調査 のうち病院でのオーダリングシステム導入状況を病床規模別に実数で比 較したものである。一般病院全体では、633、931、1274、1882、2448 機関と年次を追って増えており、特にここ 3 年では 600 近く増えている。 一方、図 3.3 は診療所も含めた最近 2 回の調査における電子カルテの導 入状況であるが、一般病院では H20 調査で一部導入を含めると導入済み は 14.2%、具体的に導入予定があると回答した病院数は 16.8%ある。半 数が実際に 3 年後までに導入すると仮定すると H23 年には約 23%の導入 率になるであろう。また 150-199 床規模の病院に限定すると、全体導入 済み機関は H17 年 5.7%、H20 年 10.1%の導入率であり、一般病院全体 の導入率よりやや下回っているが平均的であると言え、増加傾向は規模 によらずここ 3 年で 2 倍前後になっていることがわかる。しかし、図 3.2 に示すように病床規模が 50 199 の病院数が実数では非常に多いので、 医療機関同士の情報連携や医療全体での有効性を考える際には、この規 模の病院での導入率が実数に与える影響が非常に大きいことを考慮しな 8 ければならない。 3.2.2. 診療所の IT 化 図 3.3 でわかるように、診療所での電子カルテ導入率は平成 20 年度で 13％、今後数年以内に予定されている診療所を加えても 20％程度に留ま っている。もちろん 3 年ごとの調査のたびに導入率は 6 ないし 7％増加し ているので、進展が見られることは事実であるが、このペースが続くな らほとんどの診療所に普及するまでにまだ 10 年近くかかる可能性がある。 診療所の IT 化が進まないと、診療所での処方箋内容や検査結果を他の 医療機関で活用する上で、IT を利用することが困難であり、200 床未満 の病院の IT 化とともに診療所の IT 化の促進が重要な課題である。 9 図 3．2 病院におけるオーダリングシステム普及状況 10 図 3．3 診療所と病院の電子カルテ普及状況 11 3.2.3. 調剤薬局の IT 化 調剤薬局の IT 化としては、調剤レセプトコンピュータの導入とそれに よる電子レセプト対応、処方情報の安全性チェックや処方履歴管理、医 薬品情報の提供や説明書の印刷、などがある。これらは一体となってい る情報システムであることが多い。社会保険診療報酬支払基金の平成 22 年 1 月診療分レセプトの内訳公表資料によれば、調剤薬局 48099 のうち、 手書きレセプトを作成提出している調剤薬局は 3743（7.8％）と少なく、 ほとんどがコンピュータにより処理を行っている。またレセプト件数で 見ると 21,462,877 件のレセプトの実に 99.9％が電子レセプト請求とな っており、99.1％がオンライン請求となっている。このことから、調剤 実施情報はレセプト請求レベルではほぼ完全に電子化されていると判断 できる。一方で、後発医薬品を調剤した場合に加算点数を請求する条件 となっている後発医薬品への変更に関する調剤実施情報の医療機関への 返却通知については、その実態調査がなされていないため実施率が不明 であるが、一部の医療機関に対するヒアリングによれば調剤実施情報を 返却しているケースは非常に少ないとみられる。 3.3. IT による医療機関情報連携の現状 3.3.1. 医療機関情報連携のモデル 医療機関同士で診療情報連携を実現するモデルとしていくつかの形態 が提唱されている。ひとつは、データベース共用型あるいはサービス共 用型の形態で、これは複数の医療機関が共用するデータサーバあるいは 電子カルテシステムサーバをネットワーク上に設置し、そこに各医療機 関が日常診療記録を登録する方式で、Software As a Service(SaaS)型は その例である。インターネット上の ASP 型電子カルテによる情報共用や、 ひとつのビルのなかに複数の診療所がテナントとして入っていて、ひと 12 つの情報システムを共用する医療モール型と呼ばれるスタイルもこれに 含まれる。もうひとつは、必要情報オンデマンド交換型とも言えるもの で、診療情報提供や患者情報照会の必要が発生したときに、その患者の データだけを必要とする相手医療機関に電送する方式で、非常に単純な ものとしては電子メールでやりとりする形式があり、すこし複雑なもの としては情報交換用のサービスを提供する電子ボックスのようなところ に必要が生じたときにデータを預け、相手医療機関がそれを引き出すと いう形式である。また、広義にはオンデマンドデータ交換型ではあるが、 あらかじめ患者ごとの診療情報がどこの医療機関の情報システムに登録 されているかに関する所在情報をひとつのシステムに登録しておき、必 要に応じてその所在情報をもとに元の情報に自動的にアクセスする所在 情報検索型という形態もあり、米国の地域医療情報連携で実現が試みら れている XDS 形態もこれに近い。以上は、医療機関主導型といえる範疇 のものであるが、これに対して、患者主導型あるいは患者中心型情報共 有という形態がある。代表的なものは、主要な診療情報を患者が所有す るパーソナルヘルスカードなどの IC カードあるいは患者が指定するデー タ登録システムに医療機関が診療のために登録し、患者は必要に応じて 別の医療機関でそのデータを利用してもらうために提供したり引き出し てもらったりするものである。この場合には、医療機関だけでなくデー タ登録サービスに患者自身も自分で情報を登録するスタイルもあり、こ うしたサービスは、マイクロソフト Health Vault や Google Health など インターネット上のサービスとして展開が始まっている。また、患者主 導と医療機関主導の中型型の形態として、診療情報共有に参画する特定 の地域の複数医療機関が、患者の許可のもとに必要に応じて、別の医療 機関の情報システム画面にアクセスして必要な診療情報を参照する形態 があり、オリジナル情報参照型と呼べるもので、国内の地域医療情報ネ ットワークで多い形態である。地域の中核医療機関のシステムに周辺の 診療所がアクセスして必要な情報を参照する 1 対多システムもこの形態 13 のひとつといえる。 以上を整理すると以下のようになる。 表 3．1 医療機関情報連携のモデル 基本形態 サブタイプ データベース共用型 実装の方式 データベース センター 共用型 サービス共用型 SaaS 型、ASP 型 ドルフィンプロジ ェクト系 Web 版電子カルテ 医療モール型 電子メール・ 個人利用の 情報メッセージ交換型 電子メール 電子情報ボックス中継型 プロジェクト 情報中継ハブ 香川 K-MIX 電子宅配便 必要情報オンデ 米国地域医療情報 マンド交換型 ネットワーク XDS 形態 所在情報検索型 東海医療情報ネッ トワーク 患者中心型情報共有 患者指向型 オリジナル情報参照型 ネットワーク上の 個人情報ボックス MS-Health Vault Google Health VPN による医療 長崎あじさい 機関情報システム ネットワーク へのアクセス 14 3.3.2. 国内の IT による地域医療情報連携プロジェクト 国内では 90 年代後半頃から各地で、その地域内の中核病院と周辺の診 療所や病院との間で、患者の診療情報連携を ICT により実現するさまざ まな実験が、経産省、厚労省などのモデル事業などにより実施され、そ のうちのいくつかは現在も非営利運営組織が設置されるなどのより運営 が継続している。ここではその代表的なものをいくつか紹介する。 1）ドルフィンプロジェクト系サービス 2000 年度経産省研究開発プロジェクトにより吉原ら（現、京都大学病 院医療情報部）により熊本、宮崎で実験サービスが開始され、2004 年か ら本格サービスをスタートしているデータベース共用型サービスによる 登録同意患者の診療情報共用システムである。現在は後続の別のプロジ ェクトに主力サービスは引き継がれているようであるが、このプロジェ クトのサービス形態は吉原らが京都大学病院、京都府医師会、京都府立 医大などと連携して「まいこネット」として新たなサービスを展開して いる。また 2005 年からは、複数のこれら地域医療情報ネットワークをス ーパサイトにより患者ごとに連結し、データ規格の変換も同時に行い、 仮想的にネット間を統合して 1 患者 1 カルテに見えるようにする実験と して、スーパードルフィンが始まっている。（文献：吉原博幸：Dolphin Project 地域医療連携システムの現状、治療 vol90.No.2, 359-364,2008）。 ドルフィンプロジェクトでは、1 患者の診療データを地域医療情報セン ターにすべてアップロードし、そこで集約管理するスタイルを取ってい る点が特徴で、膨大な情報が医療機関から発生する今日では、地域医療 情報センターにすべての診療情報を標準化してアップロードする形態が 維持し続けられるかどうかが課題であろう。 2）あじさいネットワーク 国立病院機構長崎医療センターの電子カルテシステムにアクセス用サ 15 ーバを設置し、VPN（バーチャルプライベートネットワーク）技術によ って暗号化した診療情報をインターネット経由で診療所や中核病院から 参照可能とするもので、その接続対象は「大村市立病院」、「大村市医師 会会員医療機関約 30 ヶ所」、 「長崎県離島医療圏組合中核病院 9 ヶ所」と なっている。現在は NPO 法人長崎地域医療連携ネットワークシステムに より運営されているもので、オリジナル情報参照型ネットワークである。 診療情報を一括して受信して管理するセンターデータベースが存在しな い点でドルフィンプロジェクトと大きく異なる。 3）香川遠隔医療ネットワーク K-MIX 遠隔画像診断や患者診療情報提供を K-MIX センターにデータをアップ ロードし、相手医療機関に転送するもので、一種のデータ中継型センタ ーサーバによる情報連携を実現しており、依頼医療機関と支援医療機関 が事前登録した上で、相互間で診療情報がオンデマンドで転送される、 オンデマンドデータ交換型といえるものである。平成 21 年度以降は、経 済産業省「健康情報活用基盤構築のための標準化および実証事業」にお いて、香川県下にて、医療情報のみならず、個人の健康情報や健診情報 もあわせた医療・健康情報の統合化を目指す「e ヘルスケアバンク」を立 ち上げる計画で、これによりこれまで個人により個別に管理されていた 健康に関する情報を一元的に管理可能とする方向をめざしているようで ある。この点では最初のドルフィンプロジェクトの考え方に接近しつつ あるといえる。 3.3.3. PHR と EHR 3.2.1 の医療機関情報連携のモデルで述べたように、患者主導型で異な る医療機関での診療情報を連携して使用できるような環境に情報を投入 し利活用するスタイルは、パーソナルヘルスレコード（PHR）と呼ばれ 16 ている。もともと PHR は、IC カードのような患者が携帯する媒体に自 分の診療履歴情報を格納して必要に応じ医療機関に提示するといったニ ュアンスが強かったが、現在、少なくとも我が国では携帯型媒体に限ら ず、ネットワーク上のデータバンクに患者自身がデータを預けるスタイ ルも含んでいると考えられる。生涯型健康医療情報管理(Electronic Health Record: EHR）は、医療機関あるいは国としてのサービス視点で 表現したものであり、PHR が利用者視点での表現であることに対応して いるが、両者はコンセプトとして対立するものでもなく、目指すところ はほぼ同じであり、表現する際の視点が異なっているだけであると考え られる。ただひとつ異なる点は、EHR では、全患者のデータを匿名化し て管理できるデータベースの存在を前提もしくは肯定している点であり、 このデータベースにより臨床疫学的な解析が極めて大規模に容易にでき、 医療の質の向上に飛躍的に資すると考えられるのに対して、PHR の場合 には患者個人の診療に役立てることだけが視点となっているため、医療 全体での疫学的解析などに資する視点が欠落しているといえる。 既存の多くの地域医療情報ネットワークも、PHR であり、EHR にあ る医療全体に役立てるデータベースの構築という視点は含まれていない。 3.4. IT による救急医療における情報活用の状況 救急医療時には、普段患者がかかりつけの医療機関に搬送された場合 には問題ないが、そうでない初めての医療機関に搬送されることも多い。 医療機関にとっては、正確な診断を迅速に下すためにできるかぎり情報 が多いほうが良く、特に診療サマリーとなるような要点を簡潔に記述し た情報の価値が高い。過去の膨大な検査結果や診療経過の情報が提供さ れたところで、短時間でそれらに目を通して全貌を把握する余裕はなく、 17 むしろ無意味な情報となってしまう。それに対して、普段何の病気で何 の薬を飲んでいるか、普段の血圧や血糖値はどうか、大きな手術を受け たことがあるならその手術方法は何か、アレルギーはないかといった医 師にとって判断を左右する重要な情報だけが入手できればよい。しかし、 こうした「医師にとって重要な情報」が何であるかは患者にはわからな いことがあり、特に家族にはそれが判断できないため、必要のない情報 が延々と述べられたり、重要な情報が提供されなかったりすることが多 い。 普段かかっている医療機関でのそうした診療要約情報や、直近まで入 院していたときの入院サマリーが電子化され、救急医療時に迅速に確認 できれば、救急医療時に非常に役に立つ。しかし現状では、処方箋の内 容と直近の血液検査の結果、普段通院時の診断病名といった情報でさえ、 電子的に入手できない。この背景には、IT 化の現状で述べたように中小 医療機関や診療所でのオーダリングシステムや電子カルテの導入率が低 く、そもそもこうした要約診療情報が電子化されていないことと、電子 化されていてもそのデータを必要時に他の医療機関に電送できるシステ ムが存在しないことがある。また、院外処方情報においては調剤薬局で レセプトコンピュータがほぼ 100％導入され電子データが存在している にも関わらず、その電子データを救急診療に活用できる仕組みが存在し ていないことも原因のひとつである。 3.5. 調剤情報の病薬連携の必要性 後発医薬品処方と調剤の推進が進められている現在、医療機関が発行 した処方箋に記載されている医薬品商品名とは異なる商品名の医薬品が 後発医薬品として調剤される。処方箋を発行した医療機関では、患者が いつどこでどのような後発医薬品を調剤されたのか知る定まった方法が 存在しないため、次回以降に患者が受診した時に患者に直接確認するし 18 か、調剤に関する情報を得ることができない。 こうした問題は、制度上も認識されているため、調剤薬局では処方箋 に後発医薬品調剤を行った場合には、 「後発医薬品調剤加算」という診療 報酬点数を加算してよいこととなっているが、その条件として、 「後発医 薬品へ変更可能な処方せんに基づいて、①処方せんに記載されている先 発医薬品を後発医薬品に変更、または、②処方せんに記載されている後 発医薬品を別銘柄の後発医薬品に変更した場合には、処方せん発行医療 機関に対し、実際に調剤した後発医薬品の銘柄などの情報を提供するこ と」となっている。しかし、現実には調剤薬局が処方箋発行医療機関に 対して実際に調剤した後発医薬品の銘柄などの情報を提供するには、処 方箋ごとにその元の医療機関に対して郵便もしくは FAX 等により情報を 送付する必要があり、送付先仕分けを行うことを含め、非常な手間がか かるため現実的でなく、調剤薬局ではそれができないために後発医薬品 を調剤しないケースや、調剤しても加算点数を算定しないケースなどが 多発していると推測される。 また医療機関においても、患者が診察を終えた後日に、調剤薬局から 調剤実施情報を郵送や FAX で情報提供されても、カルテを取り出してそ れを綴じるといった作業を行うことは、手間がかかり、特に患者数の多 い大規模医療機関では事実上不可能となっている。 こうした状況から、一定の標準化された書式で調剤実施情報を、処方 箋を発行した医療機関に電送する簡単な方法を確立することが求められ る。 3.6. 医療 IT 政策と現状との関連 2001 年、厚生労働省は保健医療分野の情報化にむけてのグランドデザ インをとりまとめた。ここでは、患者の選択の尊重と情報提供、質の高 い効率的な医療提供体制、国民の安心のための基盤づくりの 3 つを 21 世 19 紀の医療提供の姿としてとりあげ、その実現のために医療施設のネット ワーク化を進めることとしている。これより前の平成 11 年には厚生労働 省健康政策局長、医薬安全局長、保険局長連名の通知「診療録等の電子 媒体による保存について」が発出され、初めて診療情報が電子的に記録 され保存されても差し支えないための 3 つの条件として、真正性、見読 性、保存性の 3 条件が提示され、診療情報の電子化、電子カルテの実現 に制度的に大きく前進した。 e-Japan 計画 2001 に基づく重点計画 2004 では、医療分野の IT 化が 以下のように大きく取り上げられた。 1． IT を活用した医療情報の連携活用 ・保健医療分野における認証基盤の開発・整備 ・電子カルテの医療機関外での保存の容認 ・電子カルテの連携活用に対応したセキュリティ等に関するガイド ラインの作成 ・電子カルテの連携活用を行う医療機関への支援 2．IT を活用した医療に関する情報の提供 ・医療情報のデータベース化、インターネットによる情報提供 3．電子カルテの普及促進 ・電子カルテの用語・コードの標準化及び相互運用性の確保 ・診療情報の電子化など医療分野での IT 利用促進 4．レセプトの電算化及びオンライン請求 ・医療機関への普及促進 ・審査支払機関及び保険者における電子レセプトへの対応整備 5．遠隔医療の普及促進 ・遠隔医療のシステム整備支援 こうした動きを受ける形で、時期的に相前後して厚生労働省、経済産 業省などで電子カルテ普及を推進する各種補助事業が実施され、全国で 50 近い地域医療情報ネットワークの実証実験が行われ、前述したいくつ 20 かの地域医療情報ネットワークもこれらの実験成果を受けたものといえ る。しかし、多くの実証実験はその後終了し、現在も運用しているもの は少ない。その原因として、継続的に運営費用を維持するビジネスモデ ルが成立していなかったことと、制度的に日常診療に組み込まれていな いことが上げられる。 2006 年にとりまとめられた新 IT 改革戦略では、医療の IT 改革を大き な柱の一つにとりあげ、 「個人が生涯を通じて健康情報を活用できる基盤 づくり」として、次の 5 つを目標として掲げている。 1．遅くとも 2011 年度当初までに、レセプトの完全オンライン化によ り医療保険事務のコストを大幅に削減するとともに、レセプトのデータ ベース化とその疫学的活用により予防医療等を推進し、国民医療費を適 正化する。 2．2010 年度までに個人の健康情報を「生涯を通じて」活用できる基 盤を作り、国民が自らの健康状態を把握し、健康の増進に努めることを 支援する。 3．遠隔医療を推進し、高度な医療を含め地域における医療水準の格差 を解消するとともに、地上デジタルテレビ放送等を活用し、救急時の効 果的な患者指導・相談への対応を実現する。 4．導入目的を明確化した上で、電子カルテ等の医療情報システムの普 及を推進し、医療の質の向上、医療安全の確保、医療機関間の連携等を 飛躍的に促進する。 5．医療・健康・介護・福祉分野全般にわたり有機的かつ効果的に情報 化を推進する。 このなかで、2 で PHR もしくは EHR の推進、5 で医療情報のネット ワーク型流通を推進することが掲げられている点が特徴である。こうし た方向性を推進する形のひとつとして、厚労省、経産省、総務省の 3 省 合同事業として、 「健康情報活用基盤実証事業」が実施され、沖縄県浦添 市をフィールドとして PHR 実証実験が行われている。 21 このように一連の政府の方針とそれにもとづく事業により、国内の医 療における IT 化は、将来に向けた目標を示しながら推進されている。し かし、医療機関の IT 化と、EHR 指向の医療機関情報連携、PHR 指向の 患者情報の診療利用に力点がおかれている一方で、医療提供側の日常の 診療実務に視点をおいた情報連携や、救急診療における診療情報利用と いった実務目的指向型の IT 化が注目されてこなかった点が、現状の医療 機関での目に見える診療上の利便性が乏しいことと関係しているように 思われる。 3.7. 診療情報連携におけるセキュリティーとプライバシー保護 3.7.1. 医療情報システムの安全管理のガイドライン 医療情報システムの安全管理のガイドラインは平成 17 年度に第 1 版が 公表されたのち、平成 22 年 2 月に第 4.1 版が公表されるまで、改訂を何 度か繰り返している。同ガイドラインは、医療情報システムにおいて個 人情報を含む診療情報を適切に運用管理する上で最も重要なものであり、 位置づけを同ガイドライン序文を引用する形で、以下に説明する。 平成 11 年 4 月の通知「診療録等の電子媒体による保存について」 （平 成 11 年 4 月 22 日付け健政発第 517 号・医薬発第 587 号・保発第 82 号 厚生省健康政策局長・医薬安全局長・保険局長連名通知）、平成 14 年 3 月 通知「診療録等の保存を行う場所について」（平成 14 年 3 月 29 日付け 医政発 0329003 号・保発第 0329001 号厚生労働省医政局長・保険局長 連名通知、平成 17 年 3 月 31 日改正、医政発第 0331010 号、保発第 0331006 号）により、診療録等の電子保存及び保存場所に関する要件等 が明確化された。その後、 情報技術の進歩は目覚しく、社会的にも e-Japan 戦略・計画を始めとする情報化の要請はさらに高まりつつある。平成 16 年 11 月に成立した「民間事業者等が行う書面の保存等における情報通信 の技術の利用に関する法律」 （平成 16 年法律第 149 号。以下「e-文書法」 22 という。）によって原則として法令等で作成または保存が義務付けられて いる書面は電子的に取り扱うことが可能となった。医療情報においても 「厚生労働省の所管する法令の規定に基づく民間事業者等が行う書面の 保存等における情報通信の技術の利用に関する省令」 （平成 17 年 3 月 25 日厚生労働省令第 44 号。以下「e-文書法省令」という。）が発出された。 平成 15 年 6 月より厚生労働省医政局に設置された「医療情報ネット ワーク基盤検討会」においては、医療情報の電子化についてその技術的 側面及び運用管理上の課題解決や推進のための制度基盤について検討を 行い、平成 16 年 9 月最終報告が取りまとめられた。 上記のような情勢に対応するために、これまでの「法令に保存義務が 規定されている診療録及び診療諸記録の電子媒体による保存に関するガ イドライン」 （平成 11 年 4 月 22 日付け健政発第 517 号・医薬発第 587 号・保発第 82 号厚生省健康政策局長・医薬安全局長・保険局長連名通知 に添付。）、 「診療録等の外部保存に関するガイドライン」 （平成 14 年 5 月 31 日付け医政発第 0531005 号厚生労働省医政局長通知）を見直し、さ らに、個人情報保護に資する情報システムの運用管理に関わる指針と e文書法への適切な対応を行うための指針を統合的に作成することとした。 なお、平成 16 年 12 月には「医療・介護関係事業者における個人情報の 適切な取扱いのためのガイドライン」が公表され、平成 17 年 4 月の「個 人情報の保護に関する法律」（平成 15 年法律第 57 号。以下「個人情報 保護法」という。）の全面実施に際しての指針が示されたが、この指針で は情報システムの導入及びそれに伴う外部保存を行う場合の取扱いに関 しては本ガイドラインで示すとされている。 このガイドラインは「医療・介護関係事業者における個人情報の適切 な取扱いのためのガイドライン」と対になるものであるが、個人情報保 護は決して情報システムに関わる対策だけで達成されるものではない。 従って、本ガイドラインを使用する場合、情報システムだけの担当者で あっても、 「医療・介護関係事業者における個人情報の適切な取扱いのた 23 めのガイドライン」を十分理解し、情報システムにかかわらない部分で も個人情報保護に関する対策が達成されていることを確認することが必 要である。 ここでは医療情報システムの安全管理のガイドラインの変遷を確認す るため、同ガイドラインの改訂履歴を引用する形で、以下に記載する。 第 1 版：平成 17 年 3 月、平成 11 年 4 月の「法令に保存義務が規定さ れている診療録及び診療諸記録の電子媒体による保存に関する通知」、及 び平成 14 年 3 月通知「診療録等の保存を行う場所について」に基づき 作成された各ガイドラインが統合され、医療情報システムの安全管理の ガイドライン第 1 版として公表された。ここでは新規に、法令に保存義 務が規定されている診療録及び診療諸記録の電子媒体による保存に関す るガイドライン（紙等の媒体による外部保存を含む）及び医療・介護関 連機関における個人情報保護のための情報システム運用管理ガイドライ ンを含んだガイドラインとして作成された、 第 2 版：平成 19 年 3 月 平成 18 年 1 月の高度情報通信技術戦略本部 (IT 戦略本部)から発表された「IT 新改革戦略」 （平成 18 年 1 月）にお いて、 「安全なネットワーク基盤の確立」が掲げられたこと、及び平成 17 年 9 月に情報セキュリティ政策会議により決定された「重要インフラの 情報セキュリティ対策に係る基本的考え方」において、医療を IT 基盤の 重大な障害によりサービスの低下、停止を招いた場合、国民の生活に深 刻な影響を及ぼす「重要インフラ」と位置付け、医療における IT 基盤の 災害、サイバー攻撃等への対応を体系づけ、明確化することが求められ たことを踏まえ、（1）医療機関等で用いるのに適したネットワークに関 するセキュリティ要件定義について、想定される用途、ネットワーク上 に存在する脅威、その脅威への対抗策、普及方策とその課題等、様々な 24 観点から医療に関わる諸機関間を結ぶ際に適したネットワークの要件を 定義し、「6.10 外部と個人情報を含む医療情報を交換する場合の安全管 理」として取りまとめる等の改定が実施され、また、（2）自然災害・サ イバー攻撃による IT 障害対策等について、医療の IT への依存度等も適 切に評価しながら、医療における災害、サイバー攻撃対策に対する指針 として「6.9 災害等の非常時の対応」を新設して取りまとめる等の改定を 実施することが明記され、第 2 版として公表された。 第 3 版：平成 20 年 3 月 第 2 版改定後、さらに医療に関連する個人 情報を取り扱う種々の施策等の議論が進行している状況を踏まえ、(1) 「医療情報の取扱に関する事項」について、医療・健康情報を取り扱う 際の責任のあり方とルールを策定し、 「4 電子的な医療情報を扱う際の責 任のあり方」に取りまとめる等の改定を実施。また、この考え方の整理 に基づき「8.1.2 外部保存を受託する機関の選定基準及び情報の取り扱い に関する基準」を改定、(2) 「無線・モバイルを利用する際の技術的要件 に関する事項」について、無線 LAN を扱う際の留意点及びモバイルア クセスで利用するネットワークの接続形態毎の脅威分析に基づき、対応 指針を 6 章と 10 章の関連する個所に追記。特にモバイルで用いるネッ トワークについては、 「6.11 外部と個人情報を含む医療情報を交換する場 合の安全管理」に要件を追加。さらに、情報を格納して外部に持ち出す 際の新たなリスクに対して「6.9 情報及び情報機器の持ち出しについて」 を新設し、留意点が記載され、第 3 版となった。 第 4 版：平成 21 年 3 月 第 3 版改定後、 「医療機関や医療従事者等に とって、医療情報の安全管理には、情報技術に関する専門的知識が必要 であり、さらに多大な設備投資等の経済的な負担も伴う」、「昨今の厳し い医療提供体制を鑑みれば、限りある人的・経済的医療資源は、医療機 関及び医療従事者の本来業務である良質な医療の提供のために費やされ 25 るべきであり、情報化に対して過大な労力や資源が費やされるべきでは ない」、「他方、近年の医療の情報化の進展に伴い、個人自らが医療情報 を閲覧・収集・提示することによって、自らの健康増進へ役立てること が期待されている」等の指摘がなされたことを踏まえ、より適切な医療 分野の情報基盤構築のため、 「医療分野における電子化された情報管理の 在り方に関する事項」について、各所より医療情報に関するガイドライ ンの整合を図ることが求められていること、また、技術進歩に合わせた 医療情報の取扱い方策について、物理的所在のみならず医療情報を基軸 とした安全管理及び運用方策等を更に体系的に検討し、読みやすさにも 配慮することとして、「3.3 取り扱いに注意を要する文書等」を新設し留 意点を明記、5 章を全般的に見直し「5 情報の相互運用性と標準化につ いて」として全面改定、「6.1 方針の制定を公表」、「6.2 医療機関におけ る情報セキュリティマネジメントシステム（ISMS）の実践」に C 項及 び D 項を設置、「6.11 外部と個人情報を含む医療情報を交換する場合の 安全管理」に外部からのアクセスに関する事項を追加、 「7 電子保存の要 求事項について」の B 項、C 項及び D 項を 7 章全体で大幅に見直し、 「8.1.2 外部保存を受託する機関の選定基準及び情報の取り扱いに関する 基準」に情報受託者が民間事業者である場合には、経済産業省及び総務 省が発出しているガイドラインに準拠することを明記、その他、技術的 要件の見直し、各種省令・通知等と A 項の関係性整理等、全般的な改定 を実施。 第 4.1 版 平成 22 年 2 月 平成 21 年 11 月の医療情報ネットワーク 基盤検討会において、診療録等の保存を行う場所について、各ガイドラ インの要求事項の遵守を前提として「「民間事業者等との契約に基づいて 確保した安全な場所」へと改定すべき」とする提言が取りまとめられた こと受けて、外部保存通知の改正を行い、本ガイドラインにおいても関 連する 4 章、8 章、10 章の一部を中心に改定を実施した。4 章では「4.3 26 例示による責任分界点の考え方の整理」に「（4）オンライン外部保存を 委託する場合」を追加した。8 章では、「8.1.2 外部保存を受託する機関 の選定基準及び情報の取り扱いに関する基準」の「③医療機関等の委託 を受けて情報を保管する民間等のデータセンターに保存する場合」を「③ 医療機関等が民間事業者等との契約に基づいて確保した安全な場所に保 存する場合」とし、内容を通知に合わせて改定した。 3.7.2. 医療における個人情報保護法 平成 15 年に成立した「個人情報の保護に関する法律」 （平成 15 年法律 第 57 号、以下個人情報保護法、または同法という）において、個人情報 の取扱いについて法律上の考え方が示され、医療機関が取り扱う診療情 報についても個人情報保護法が適用されることになった。また、個人情 報保護法第 6 条第 3 項及び第 8 条の規定に基づき、同法の対象となる病 院、診療所、薬局、介護保険法に規定する居宅サービス事業を行う者等 の事業者等が行う個人情報の適正な取扱いの確保に関する活動を支援す るためのガイドラインが「医療・介護関係事業者における個人情報の適 切な取扱いのためのガイドライン」（平成 16 年 12 月 24 日厚生労働省） として定められた。以下ではそのガイドラインの位置づけを序文から引 用して説明する。 個人情報の取扱いについては、同法第 3 条において、 「個人情報が、個 人の人格尊重の理念の下に慎重に取り扱われるべきものである」とされ ていることを踏まえ、個人情報を取り扱うすべての者は、その目的や様 態を問わず、個人情報の性格と重要性を十分認識し、その適正な取扱い を図らなければならない。 特に、医療分野は、「個人情報の保護に関する基本方針」（平成 16 年 4 月 2 日閣議決定。以下「基本方針」という。）及び国会における附帯決議 27 において、個人情報の性質や利用方法等から、特に適正な取扱いの厳格 な実施を確保する必要がある分野の一つであると指摘されており、各医 療機関等における積極的な取組みが求められている。 また、介護分野においても、介護関係事業者は、多数の利用者やその 家族について、他人が容易には知り得ないような個人情報を詳細に知り うる立場にあり、医療分野と同様に個人情報の適正な取扱いが求められ る分野と考えられる。 このことを踏まえ、同ガイドラインでは、同法の趣旨を踏まえ医療・ 介護関係事業者における個人情報の適正な取扱いが確保されるよう、遵 守すべき事項及び遵守することが望ましい事項をできる限り具体的に示 しており、各医療・介護関係事業者においては、法令、基本方針及び本 ガイドラインの趣旨を踏まえ、個人情報の適正な取扱いに取り組む必要 がある、とされている。 従って、医療機関が情報ネットワーク等を用いて診療情報をやりとり する上では、前項の「医療情報システムの安全管理のガイドライン」と 合わせて本ガイドラインを遵守することが必要となる。 3.8. 諸外国の医療 IT 化の状況と比較 国内の医療機関の IT 化については 3.1.3 節で述べた。欧米の先進工業 7 カ国における医療情報の電子化率が公表されており、それによれば、オ ーストラリアやオランダ、ニュージーランド、イギリスではプライマリ ケア医の電子カルテ（EHR）の利用が 90％以上、ドイツも 40％から 80％ 程度の導入率であった。それに対しアメリカとカナダでは、一貫して電 子カルテを利用するプライマリケア医は 10％から 30％程度で、オーダリ ングシステムについては、電子カルテの導入率より 10 ポイントほど下回 る数値で導入が行われていることが、表 3.2 からわかる。 28 病院における電子カルテの導入率については、どの国でも 10％に満 たない。病院におけるオーダリングシステムの導入率についてはアメリ カの 5％から 10％が最高で、いずれの国もオーダリングシステムの導入 は低い水準にとどまっている。 日本の一般診療所における電子カルテの導入率は、07 年で 7.6％であ り、国際的には低い。一方、病院の電子カルテの導入率は各国とも 10％ 以下と予想されその値は軒並み低く、日本も 7.4％とこれに並んでいる。 このことから、懸念すべきは一般診療所や小規模な病院における医療情 報の電子化であり、これらは国際的に日本が遅れているといえよう。 表 3．2 欧米と日本の電子カルテ（EHR）およびオーダリングシステ ム(CPOE)の普及率の比較 29 3.9. 医療における高度情報連携の必要性と課題 3.9.1. 高度な情報連携の必要性 医療機関における診療情報連携の形態では、大きく分けて 2 つのパタ ーンが存在する。ひとつは、医療機関がある患者を別の医療機関に紹介 するために必要な診療情報を提供するもので、いわゆる患者紹介に伴う 診療情報提供である。もうひとつは、患者が受診した医療機関が、診療 上の必要から、その患者が以前に受診していた別の医療機関に診療情報 の提供を要請し、それに対応して要請された医療機関が診療情報を提供 するものであり、このなかには救急でない場合と、救急診療時の情報提 供の両方のケースが含まれる。 どちらの場合にも、書類で情報提供がなされることが多かったが、現 在では医療画像データや検査データなど大量の診療情報を提供する必要 がある場合も少なからずあり、電子データによる大量の情報提供が必要 な場面が増えつつある。 また、救急診療時のケースでは、以前に受診した医療機関に時間外や 休日であるためにすぐには連絡がとれず、必要な診療情報が即時に入手 できないこともあり、あらかじめ必要な診療情報をどこかに登録してお くか、または患者に保有させておくことにより必要時に迅速に利用でき るようにしておくことが望まれる。この場合でも診療してみて始めて必 要性が生じるような詳細なデータ、たとえば過去の手術記録や医療画像 データなどでは、あらかじめすべてのデータを必要に備えて登録してお くことは難しく、なんらかの解決法が必要である。 さらに、調剤薬局から医療機関への調剤実施情報の提供は、薬局が後 発医薬品を調剤した場合にその調剤実態に関する情報を医療機関側で把 30 握したい場合に必要となり、また調剤薬局で後発医薬品調剤に関する保 険診療点数を算定するには調剤実施情報を医療機関側に提供することが 求められていることからも必要性が高まっている。 3.9.2. 医療機関における情報連携の課題 前述したような高度情報連携の必要性に対応していくために解決すべ き課題を考える上で、サービスモデル上の課題、それを支える技術課題、 サービスをスムーズかつ安全に運用できるための制度面やルール面の課 題の 3 つに分けて考えるのが妥当である。 1）サービスモデル上の課題 サービスモデル上の課題としてここでは 2 つ取り上げる。現状では、 医療機関や調剤薬局が、別の機関に診療情報を電子的に送信しようとし たときに、（1）送り先機関の電子アドレスが一意に定まっておらず送り 先アドレス検索サービスが存在しないこと、（2）郵便局や宅配業者に相 当する確実で信頼できるサービスを実施している医療情報電送サービス 業者が存在しないこと、の 2 点である。 郵便や宅配業者で物品を送付する場合、送り先相手に郵便住所を確認 し、送りたい物品に一定の書式でその住所を記載するか所定の伝票に記 入して貼付し、料金を所定の方法で支払えば、あとは確実に配送が可能 である。また付加的なサービスを利用すれば、配送状況の確認ができ、 受取証明や配送証明も必要なら取得できる。このように、物品送付にお いては、配送サービス業者が存在し、配送先情報として送り側および受 け取り側双方が特定できる郵便住所が存在し、それを配送業者に所定の 方法で伝えることにより配送が確実に実現できる。 一方、電子情報の送信では、確かにインターネット上の電子メール、 ファイル電送サービスや、ファイル暗号ツールなどは存在する。しかし、 31 医療機関として診療情報を受けるための一意に定まる特定の電子メール アドレスがすべての医療機関にただひとつだけ確実に存在するというこ とはないし、医療機関が毎日定期的にそのメールアドレスに届くメール を受信している保証はなされていない。仮に相手医療機関に、診療情報 を電子メールで送りたいのでアドレスを教えるように問い合わせると、 回答できる医療機関もあるが、困惑する医療機関、そのようなアドレス はないと回答するケース、特定の担当事務職員のメールアドレスを回答 するケースなどまちまちであり、このようなことは郵便住所ではあり得 ないことである。 また仮に電子メールアドレスが確定したとしても、データを暗号化し て送る方法にはいろいろな手法があり、暗号化ツールも種々存在し、ど れで暗号化するのか、あるいはそもそも暗号化しないのかについて、送 信者側と受信者側とで事前に協議しておかなければ送信できない。暗号 化しない電子メールで送信するのが一番簡単であるが、診療情報をイン ターネット上で暗号化しないで送信するのは、さすがに躊躇する医療機 関が多いのは当然であろう。 事前に送付する可能性のある相手医療機関と個々の医療機関が協議し ておかないといけないのでは、患者 1 人の情報を、診療上の必要に応じ てその患者ごとに異なる相手医療機関に電子的に診療情報を送信するの は、技術的には可能であっても現実には不可能である。ましてや、診療 所が地域の中核病院や専門病院に患者を紹介し電子的に診療情報を送信 する必要が生じるケースは、少ない場合には月に 1 2 件以下のこともあ り、そのたびに事前に相手医療機関と交渉するのは現実的ではない。そ もそも相手医療機関にとっても、電子メールアドレスや暗号化方法につ いて、正しく回答できるような知識のある担当者がいることはあまり期 待できない。 こうした状況は、調剤薬局が医療機関に調剤実施情報を電送したい場 合にも顕著に問題となる。調剤薬局ではすでに電子化レセプト率が 90％ 32 を越えており、電子的な調剤情報が管理できている薬局が多い。しかし、 調剤薬局には、さまざまな医療機関で発行された処方箋が患者により持 ち込まれ調剤されるため、調剤実施情報を電子的に医療機関に返送する ためには、処方箋を発行した多くの医療機関の返送先電子アドレスを取 得し、相手が受け取ることのできる暗号化手法で暗号化して送信するこ とが必要となる。しかし、患者が任意に持ち込んでくる処方箋の発行元 医療機関は事前に特定できず、極論すれば日本中どこの医療機関の処方 箋でも持ち込まれる可能性がある。 以上のことから、電子的に診療情報を送信するには、送りたいと考え た相手先医療機関の電子アドレスが一意に定まって、それを送り先とし て設定できるアドレス検索サービス、もしくは電子送付先医療機関指定 のためのサービスが必要である。 その上で、送付側から見れば、その電子送付先医療機関を指定して、 あるひとつのサービスに電子配送を委託すれば、確実に配送され、受信 状況が確認できることが必要となる。また受信側からみれば、そのサー ビスから電子配送がなされたことが確実に通知され、受信がなされる仕 組みが運用される必要がある。 2）技術的課題 技術的課題としては、前項のサービスを実現する上で必要となる、医 療機関や調剤薬局など医療関連機関が、電子的に診療関連情報を送信し たい相手先の医療関連機関に対して、簡単に送信する技術方法を確立す ることである。 第一に、医療機関または薬局から、電子医療情報配送サービス提供者 に確実かつ安全に電子診療情報が届けられること、および電子医療情報 配送サービス提供者から確実かつ安全に医療機関または薬局へ電子診療 情報が届いていることが通知され、受信できることが実現されることで 33 ある。そのためにはセキュリティー面で、医療情報の安全管理のガイド ラインを満たす必要がある。 第二に、医療機関が有する既存の情報ネットワーク (LAN)と、電子医 療情報配送サービス提供者へ接続するネットワーク経路とを、その医療 機関の情報セキュリティーポリシーに合わせた形で接続または隔離して、 サービスが利用できるようにすることである。 第三に、電子医療情報配送サービス提供者における配送状況を、送信 者、受診者の双方がいつでも確認でき、送信者側は配送の取り消しがで きること、および当該情報の当事者たる患者が、必要ならばその配送状 況を確認でき、送信者に対して配送をやめさせることができるような技 術を確立することである。 第四に、全国の医療機関の電子アドレスを恒常的に維持管理し、電子 医療情報配送サービス提供者や送受信者が容易に検索できるようにする 技術を確立することである。また郵便住所と異なり、この電子アドレス に、診療情報や医療関係する情報以外の種々雑多な情報が SPAM メール のように届けられるようになると、電子情報であるがために膨大な不要 情報が届けられ診療業務遂行に弊害をもたらす可能性があり、そのため にこの電子アドレス自体が事実上使えなくなるリスクがある。そこで、 この電子アドレスの検索および電子アドレスへの送付は、後述する一定 のルールを満たす機関や業者だけが可能であるようにし、その技術面で の実現が必要である。 3）制度およびルール面の課題 前述した電子医療情報配送サービスと電子アドレス検索およびその利 用規制を実現するためには新たな制度やルール整備が必要であると考え られる。 具体的には、 ①電子医療情報配送サービスの実現に必要な運用ルール、 34 ②医療安全管理のガイドラインに準拠するための接続ルール、 ③同サービスを実施することができる組織の必要条件と十分条件、 ④同サービスとそれを利用する医療機関あるいは調剤薬局との契約条 項や免責条件、 ⑤医療機関ごとに一意に定められた電子アドレスの収集ルールやその 維持管理および検索の運用ルール、 ⑥医療機関の電子アドレスを取得して配送サービスを利用できる機関 の条件、 などを整備する必要が想定される。またこうしたサービスの実現と適 正な運用のために、現在の制度上のルールの緩和が必要となる可能性が ある。 さらに診療情報提供にあたっては、電子的であるないにかかわらず患 者の同意の必要性の有無をどのように解釈するかについて個人情報保護 に関するガイドラインが存在しているが、上述のサービスを利用して診 療情報を電子的に配送することを依頼したり、救急診療上の目的で一定 期間蓄積したりするような場合には、同ガイドラインの改訂が必要にな る可能性がある。 4. 目的 医療機関等（診療所、病院、調剤薬局など）がスムーズかつ安全に診 療情報を相互に送信または受信できるようにするため、電子医療情報配 送サービスに相当する機能の実証実験を行い、運用のために必要となる ルール整備の在り方について課題を整理し、その提言に向けた検討をお こなうことを目的とする。 35 5. 具体的目標 1）電子医療情報配送サービスの実現に必要な運用ルール、医療安全管 理のガイドラインに準拠するための接続ルール、同サービスを実施する ことができる組織の必要条件と十分条件、同サービスとそれを利用する 医療機関あるいは調剤薬局との契約条項や免責条件を検討するために、 電子医療情報の配送を集中的に仲介する「地域医療情報連携ハブ」を構 築し、診療所、調剤薬局、病院の間で診療情報を配送する実験を行い、 その結果をもとに各ルールや条件を整理し、提言のポイントをまとめる。 2）医療機関ごとに一意に定められた電子アドレスの収集ルールやその 維持管理および検索の運用ルール、医療機関の電子アドレスを取得して 配送サービスを利用できる機関の条件、などの整備を検討するために、 医療機関の公開鍵ディレクトリサービスを前述の地域医療情報連携ハブ の機能のひとつとして実装し実証実験を行うことにより、その結果をも とに各ルールや条件を整理し、提言のポイントをまとめる。 3）電子的な診療情報提供や救急時に必要となる電子診療情報の地域医 療情報連携ハブへの事前預託と削除などの患者による情報コントロール について、前述の地域医療情報連携ハブの機能のひとつとして実装し実 証実験を行うことにより、患者の同意の必要性の有無を現在の個人情報 保護ガイドラインをもとに検討するとともに、地域医療情報連携ハブで の情報の配送状況把握機能の必要性とその運用ルールについて検討し、 提言のポイントをまとめる。 36 以上について、課題と具体的目標、目的との関係を図示すると次のよ うに整理される。 6. 実証実験の構成、方法および実施体制 6.1. 地域医療情報連携ハブの考え方 診療情報をネットワークを利用して外部と交換する場合、送信元から 送信先に確実に情報を送り届ける必要があり、 「送付すべき相手に」、 「正 しい内容を」、 「内容を覗き見されない方法で」送付しなければならない。 送信元の送信機器から送信先の受信機器までの間の通信経路において上 37 記内容を担保する必要があり、送信元や送信先を偽装する「なりすまし」 や送受信データに対する「盗聴」及び「改ざん」、通信経路への「侵入」 及び「妨害」等の脅威から守らなければならない。医療機関等がこうし た脅威に対する対策を行う責任を課せられており、個々の機関で実施す ること自体が大きな負担、情報連携推進の障壁となり得る。地域医療情 報連携ハブを実現することにより、こうした対策が施された交換基盤を 医療機関等に提供し、情報連携における個々の機関への対策負担を軽減 させることが期待できる。 ネットワークを介した外部との情報交換における個々の脅威と対策に 対しては、厚生労働省の「医療情報システムの安全管理に関するガイド ライン（第 4.1 版）」において、以下のように列記されており、本事業に おける地域医療情報連携ハブの実現においても対策を講じることが必要 となる。 1）「盗聴」の危険性に対する対応 ネットワークを通じて情報を伝送する場合には、盗聴は様々な局面で 発生する。例えば、ネットワークの伝送途中で仮想的な迂回路を形成し て情報を盗みとったり、ネットワーク機器に物理的な機材を取り付けて 盗みとる等、必ずしも医療機関等の責任といえない事例も想定される一 方、ネットワーク機材の不適切な設定により、意図しない情報漏えいや 誤送信等も想定され、このような場合には医療機関等における責任が発 生する事例も考えられる。医療機関等においては、万が一、伝送途中で 情報が盗みとられたり、意図しない情報漏えいや誤送信等が発生したり した場合でも、医療情報を保護するために適切な処置を取る必要がある。 そのひとつの方法として情報に対する暗号化が考えられる。どの様な暗 号化を施すか、また、どのタイミングで暗号化を施すかについては伝送 しようとする情報の機密度や医療機関等で構築している情報システムの 38 運用方法によって異なるが、少なくとも情報を伝送し、医療機関等の設 備から情報が送出される段階においては暗号化されていることが望まし い。 2） 「改ざん」の危険性への対応 ネットワークを通じて情報を伝送する場合には、正当な内容を送信先 に伝えなければならない。情報を暗号化して伝送する場合には改ざんへ の危険性は軽減するが、通信経路上の障害等により意図的・非意図的要 因に係わらず、データが改変されてしまう可能性があることは認識して おく必要がある。ネットワークの構成によっては、ネットワーク自体に 情報の秘匿化機能が不十分な場合もあり、改ざんに対する対処は確実に 実施しておく必要がある。なお、改ざんを検知するための方法としては、 電子署名を用いる等が考えられる。 3）「なりすまし」の危険性への対応 ネットワークを通じて情報を伝送する場合、情報を送ろうとする医療 機関等は、送信先の機関が確かに意図した相手であるかを確認しなくて はならない。逆に、情報の受け手となる送信先の機関は、その情報の送 信元の医療機関等が確かに通信しようとする相手なのか、また、送られ て来た情報が確かに送信元の医療機関等の情報であるかを確認しなくて はならない。これは、ネットワークが非対面による情報伝達手段である ことに起因するものである。例えば通信の起点と終点の機関を適切に識 別するために、公開鍵方式や共有鍵方式等の確立された認証の仕組みを 用いてネットワークに入る前と出た後で相互に認証する等の対応を取る ことが考えられる。また、改ざん防止と併せて、送信元が正当な送信元 であることを確認するために、診療情報等に対して電子署名を組み合わ せることも考えられる。 39 地域医療情報連携ハブは、こうした医療機関等の情報連携における危 険性への対応を施しつつ、病院・診療所・調剤薬局間に介在し、安心か つ、安全に診療情報の施設間での伝送を目的とする。診療に必要な各種 情報を宛先を指定して暗号化・送付することにより、地域医療情報連携 ハブ上で暗号化された状態で一時保管され、送信先となる医療機関のみ が復号・参照可能な運用を実現する。 また、本事業における地域医療情報連携ハブの特徴として、救急時診 療における参照を目的とした患者基礎情報の登録を実現する。事前に 個々の医療機関において患者の基礎情報を登録しておくことにより、救 急医療機関が必要に応じて患者の情報を検索・参照することを可能とす る。この救急診療向けの基礎情報に対しても適切な暗号化を施した状態 で地域医療情報連携ハブ内に保持し、事前登録された救急医療機関のみ が復号・参照可能な機能を提供する。 いずれの場合も、医療機関の外部に診療情報を一時保存することにな るが、地域医療情報連携ハブの運用主体は、行政機関や民間事業者等と なる場合が十分に想定され、特別な配慮をする必要が生じる。地域医療 情報連携ハブを運用する事業者が独自に分析、解析等を行うことは医療 機関等及び患者の同意がない限り許されない。技術的な方法としては、 例えばトラブル発生時のデータ修復作業等緊急時の対応を除き、原則と して医療機関等のみがデータ内容を閲覧できることを担保することが考 えられ、地域医療情報連携ハブに保存される個人識別に係る情報の暗号 化を行い適切に管理したり、事業者等の管理者といえども通常はアクセ スできない制御機構を有することが望ましい。 こうしたネットワークを通じた診療情報交換、診療情報の外部保存に 係るおもに情報保護の観点からの対策を集約した地域医療情報連携ハブ 40 を実現し、複数の医療機関がサービスを利用できる環境を実現すること により、安全管理の水準を一定のレベルに維持することが可能となると ともに、個々の医療機関等での実施負担も低減することが可能となり、 地域医療情報連携の促進の一助となるものと考える。 地域医療情報連携ハブを利用することにより、医療機関同士の診療デ ータの連携が情報管理上の不安を抱かずに実現でき、医療の質の向上と 効率化が期待され、また、救急診療時に必要な普段の診療情報がスムー ズに電子的に利用できることによる救急医療サービスの質の向上も期待 される。 6.2. 地域医療情報連携ハブの機能 本事業で実現する医療機関等の間での診療情報交換や診療情報共有を 目的とした利用、および前章で述べたようなネットワークを通じた診療 情報交換や医療機関等の外部への診療情報の保存に対する危険性への対 策を考慮しつつ、地域医療情報ハブを含むアプリケーションには以下の 機能を実現する。 1）接続回線の暗号化 医療機関等からの地域医療情報連携ハブの利用においては、インター ネット VPN を用いた暗号化回線接続を基本とする。前述の盗聴などの危 険性への対策として、通信回線自体を暗号化する。また、VPN 接続を経 由しないと本ハブのサービスには到達できない構成とすることにより、 ハブセンター内のサーバへのアクセスを参加機関のみに限定することが 可能となり、オープンなサービスと比べ第三者からの攻撃に対してより 安全なサービス形態とすることが可能となる。VPN 接続のための設定情 報は、参加機関の申請・登録時に配布する運用を想定する。 41 2）利用機関認証機能 各参加機関へは、機関ごとに電子証明書を配布する。公開鍵基盤(Public Key Infrastructure, PKI)を用いて、発行した電子証明書をアプリケーシ ョンで使用し、ハブセンターへの接続時のクライアント認証を行う。ま た、参加機関に対して発行した電子証明書は、後述する診療情報の暗号 化・復号化にも利用する。 3）診療情報交換機能 送付先となる宛先機関を選択し、患者情報を指定した上で各種の診療 情報を入力、またはファイル選択して送付するインターフェイスを提供 する。宛先機関は、登録された機関一覧からひとつ選択が可能であり、 患者情報は、氏名、患者番号、生年月日を最低限指定する。 送付可能な診療情報は「診療情報提供書」「画像検査結果」「検体検査 結果」 「その他文書」から選択し、一回の送信で複数種別の情報をまとめ て送付可能とする。「診療情報提供書」「検体検査結果」は、データ入力 用インターフェイスを用意し、入力したデータを HL7 CDA に準拠した XML ファイルとして送信する機能を有する。 「画像検査結果」は DICOM 形式のファイルを、「その他文書」は PDF 形式のファイルを指定可能で ある。一回の送信分の情報は、後述する暗号化機能によりハブセンター に暗号化された 1 ファイルとして登録される。登録時には、送信先とな る医療機関あてに送信通知のメールが事前登録されたメールアドレスに 送信される。 送信先の医療機関は、アプリケーションの起動・認証手続きを経て、 送付された診療情報を閲覧することが可能である。受信一覧から必要な 診療データを選択して表示することにより、センターに登録された個々 の診療データをダウンロード、復号化し閲覧することが可能である。な お、閲覧時の利便性の向上のため、HL7 CDA 形式の XML を PDF 形式 42 に、DICOM 形式の画像データを JPG 形式に変換して参照する機能を持 たせる。 なお、どの診療データをどの機関が参照したかの履歴をアプリケーシ ョンサーバ上に保持し、参照履歴を閲覧可能とする。 センターに登録された診療情報は一定保持期間を経て削除する機能を もたせ、利用機関にダウンロードされた個々の診療データは、アプリケ ーション終了時にクライアントコンピュータから削除する機能を持たせ る。 4）診療情報の暗号化・復号化機能 宛先機関、患者情報、診療情報を指定して送信操作を行った後に、ハ ブセンターに登録される情報は、S/MIME(Secure MIME)方式での暗号 化を行う。具体的には、送信する情報を 1 つの ZIP ファイルに圧縮し、 送信元機関の秘密鍵での署名の後に、送信先機関での公開鍵による暗号 化を施す。受け取り側は、暗号化されたファイルを受信後に、自機関の 秘密鍵で復号化を行い、添付された署名を検証することが可能である。 5）機関向け公開鍵ディレクトリサービス 送信先の医療機関を指定して、上述の S/MIME 方式での暗号化を施す ためには、送信元医療機関は送信の都度、送り先の医療機関の公開鍵を 入手する必要がある。参加機関が随時変動することを考慮すると、公開 鍵の入手機能（いわゆるディレクトリサービス）は、本ハブセンター上 に実現する必要があり、診療情報交換のアプリケーションサービスと並 列して実現する。各機関にユニークな機関番号を指定して、公開鍵を取 得するインターフェイスを用意し、アプリケーションと連携して動作す る。 参加機関の登録にあたり、参加機関向けの鍵ペアの発行・配布と同時 に、本ディレクトリサービスへの公開鍵の登録をサービス管理者が行う 43 運用を想定する。 6）救急診療向け基礎情報登録・閲覧機能 救急診療向け基礎情報は患者単位で、各医療機関が随時データ入力可 能なインターフェイスを用意する。診療情報交換と同様に、氏名・患者 番号・性別・生年月日などの患者識別情報を入力し、基礎情報として、 「ア レルギー情報」 「直近処方情報」 「病名」 「留意事項」などの情報を構造化 して入力する。入力された情報は、HL7 CDA に準拠した XML 文書に整 形され、ハブセンターに暗号化して登録する。 暗号化自体は、宛先医療機関を指定した場合と同じであるが、救急診 療向け基礎情報登録専用に仮想の機関を設け、参加機関と同様に鍵ペア を発行しておき、その公開鍵を用いて暗号化を施す。 登録された基礎情報は、救急参照可能機関として設定されたクライア ントのみが閲覧可能な制限を設ける。閲覧は診療情報交換と同様に登録 された一覧から必要な情報を選択し、クライアントコンピュータ上にダ ウンロード、復号化の後に参照する。ただし、復号のための秘密鍵はハ ブセンター内だけに保持し、参照要求の都度、アプリケーションサーバ 上で、いったん救急向け仮想機関の秘密鍵で復号し、閲覧依頼元機関の 公開鍵で暗号化した後にダウンロードさせることとする。 なお、基礎情報の閲覧についても、アプリケーションサーバ上に参照 履歴を保持し、いつ、どの機関がどのデータを復号・参照したかが記録 される。 7）患者同意書登録機能 本ハブサービスの利用における、個別の患者同意書をハブセンター上 に登録する機能を持たせる。医療機関ごとの患者番号と氏名、生年月日 とともに、同意書をスキャンした電子ファイルを指定するインターフェ イスを用意する。 44 同意書登録の有無を、診療情報交換・救急基礎情報の登録時にチェッ クする機能を持たせる。 8）患者による閲覧・コントロール機能 本ハブセンター上に登録された診療データの履歴を患者が直接参照す るインターフェイスを用意する。ハブセンターに Web インターフェイス を用意し、患者自身が配布された認証情報を用いてログインし、自身の 診療データの交換履歴や参照履歴を閲覧することを可能にするとともに、 登録済データの削除依頼を行うことも可能とする。また、メールアドレ スを登録しておくことにより、自身のデータが参照された際に、メール による通知を受け取ることも可能とする。また、登録された同意書の撤 回を行うとともに、登録データの削除依頼を行うことを可能とする。 本サービスの認証情報は、医療機関が使用するアプリケーション内で 発行が可能である。 9）利用機関登録機能 主にサービス管理者が使用する。ハブサービスの利用申請を受けて、 サービス管理者は、鍵ペアの発行と、アプリケーションへの機関登録を 行う運用を想定する。 6.3. 地域医療情報連携ハブの実装方法 6.3.1. ハードウェア構成 地域医療情報連携ハブセンターのハードウェアは以下のサブシステム により構成した。 参加医療機関および、調剤薬局からは、インターネット VPN または SSL を介した暗号回線を使用してアプリケーションサーバと接続し、診 45 療データおよび調剤実施情報を送受信する。なお、サーバ・クライアン ト間でやりとりされる診療情報は原則として、送信元機関側で送信前に 暗号化を行い、送信先機関側で受信後に復号化して利用する。 1）VPN ゲートウェイ 医療機関向けのアプリケーションは、回線の暗号化および、サービス インターフェイスの隠蔽のため、VPN 接続完了後にはじめて利用可能と する。VPN 接続用のプロファイルは、本アプリケーション利用向けに事 前に作成しておき、機関の参加登録時に、VPN クライアントソフトとと もに配布することとする。 2）診療情報連携向けアプリケーションサーバおよびデータベースサー バ 医療機関間で診療情報を交換するためのアプリケーション機能、およ び、患者が Web ブラウザ等を用いて、自身の診療データの交換履歴を確 認するためのサーバ機能を提供する。 3）調剤実施情報連携向けアプリケーションサーバおよびデータベース サーバ 調剤薬局から医療機関への調剤実施情報の送信および、送信された調 剤実施情報の医療機関側での受け取りに使用するサーバ機能を提供する。 4）公開鍵ディレクトリサーバ 医療機関間で交換する診療情報は送り先だけが読み取り可能な S/MIME 方式の暗号化を施すため、送り先の情報を指定して、その公開 鍵を取得するサービスを本サーバで提供する。 5）認証局システム 46 暗号、および認証に使用する参加機関向けの鍵ペアは、新たに構築し たプライベート CA を用いて発行、配布した。また、発行された参加機 関の公開鍵は、上記のディレクトリサーバにインポートして使用する。 システムの全体構成を図 6.1 に示す。ハブセンターのシステムは東京大 学医学部附属病院の敷地内に設置し、学内ネットワークと接続する。た だし、論理的アドレス空間は、病院ネットワークとは別に配置し、第三 者的位置づけで接続を行った。 センターサーバは、アプリケーションサーバおよびデータベースサー バを同じサーバ上で実装し、アプリケーションで使用するデータベース 領域や各クライアントからアップロード・ダウンロードされる診療デー タは、サーバに Fiber Channel で接続された外付けディスク装置の記憶 領域に保持する。なお、外付けディスク領域は内部で二重化がされてお り、実行容量としては、1.4TB を用意した。 図 6.1 地域医療情報連携ハブの構成 47 6.3.2. 接続回線の暗号化 ハブセンター内のサーバと参加機関のクライアントコンピュータでや りとりされる診療データは、先に述べたように送受の際は原則として、 暗号化された状態で取り扱う。したがって、ネットワーク接続における 暗号化については、IPSec(Layer3)または SSL(Layer4)から状況に応じて 選択することとする。 診療情報連携向けアプリケーションでは、実質参加機関が事前登録さ れた機関に限定されるため環境を詳細に指定可能であること、インター ネット上にオープンにしない、という方針をもって、IPSec による VPN 接続を用いることとする。これにより、ハブセンター上のアプリケーシ ョンサービスは、VPN ゲートウェイで防護され、専用クライアントによ る VPN 接続後に初めて利用可能となる。 これに対して、患者向けのアプリケーションは、クライアント側の環 境や接続元が多岐にわたり、インターネット上にオープンであることが 必要となる。したがって、専用ソフトによる IPSec 接続のような回線で はなく、SSL による実装とした。なお、患者向けのアプリケーションで は、後述のように、診療データの内容そのものは表示せず、医療機関間 での送受信の履歴のみである。 調剤実施情報連携向けのアプリケーションは、調剤薬局側の環境に制 約がある場合が多く、新たに VPN 接続を構築することが困難な場合が多 い。今回は、SSL によるサービスとして実装した。 なお、VPN 接続には以下のハードウェア、ソフトウェアを使用した。 ハードウェア： Cisco Systems 社、ASA 5520 ソフトウェア： Cisco Systems 社、VPN Client 4.8 VPN 接続方式： IPSec over TCP 48 6.3.3. 診療情報連携向けアプリケーション 6.3.3.1. 実行環境 以下に、診療情報連携向けアプリケーションの実行環境を記す。 各機関からの送信前の暗号化、および受信後の復号化といったクライ アント側処理の実装が必要であるが、アプリケーションの配布や更新の 容易さから、本実証実験システムでは、Java Web Start を用いて実装 した。開発言語は Java である。 医療機関向けのアプリケーションでは、SSL クライアント認証を実現 し、クライアントに対するアプリケーションインターフェイスは、SOAP により提供する。DBMS は、医療機関の属性情報や、送受信される診療 データおよび送受信履歴情報などを保持するために使用する。サーバ上 に保持される診療データは、暗号化されてファイルシステム上に配置す る。 また、同一のアプリケーションサーバにおいて、患者向けのアプリケ ーション機能を JSP により実装した。 サーバ OS： Red Hat Linux Ver. 5.3 アプリケーションサーバ： Apache Tomcat 5.5.23 フレームワーク(SOAP)： Apache Axis2 1.5.1 フレームワーク(JSP)： Apache Struts 1.2.9 DBMS： PostgreSQL 8.1.19 JAVA： JDK(JRE) 1.6.0 クライアント OS： Microsoft Windows XP SP3 JAVA： JDK(JRE) 1.6.0 49 Web ブラウザ： Internet Explorer 6 SP3(以降) 6.3.3.2. 基本機能構成 クライアント上の画面機能の一覧を図 6.2 に示す。スタートページから Java Web Start により Java アプリケーションを起動した後に、認証画 面を経て各機能が利用可能となる構成とした。認証後のクライアントア プリケーションの画面の概観を図 6.3 に示す。各機能は、タブ画面で構成 されており、必要な機能をすぐに使用することが可能である。 1）データ送信 2）送信データ履歴表示 3）受信データ一覧表示 4）救急向け基礎情報登録 5）患者認証情報登録 6）同意書登録 の各画面機能を用意し、救急向け基礎情報が参照可能な設定がされた クライアントでは、これらに加えて、救急向け基礎情報の検索・表示機 能が利用可能となる。 図 6.2 画面遷移図 （次ページ） 50 図 6.3 クライアント画面の概観 51 6.3.3.3. 認証機能 本アプリケーションにおける認証機能は、2 つのものを実装した。 一つ目は、クライアントアプリケーションがサーバと SOAP 通信を行 う際の、SSL クライアント認証機能、2 つ目はクライアント起動時のユ ーザ認証機能である。 SSL クライアント認証機能は、クライアントアプリケーション内部に 保持した機関向けの証明書を使って、ハブセンターのアプリケーション サーバと SOAP 通信をする際に都度チェックがかかる。証明書の発行に は、後述のように、「機関英語名称」と、数字 10 桁の「機関コード」を 使用する。 機関コードは、特定健診で使用される健診機関・保健指導機関コード に倣い、レセプト電算システムで用いるコードをもとに以下のように表 現し、機関コードがユニークになるようにする。 「機関コード」＝「都道府県番号（2 桁）＋機関区分コード（1 桁）＋ 保険機関コード（6 桁）＋チェックデジット（1 桁）の計 10 桁」 クライアント上の認証機能は、アプリ起動時に利用者を識別するため の機能であり、クライアント PC 内に作成されたユーザ ID とパスワード を入力することによって、パスワードチェックを行い、利用者が誰であ るかを識別可能とする。本認証機能は、Shaj(Simple Host Authentication for Java)ライブラリ(http://opensource.cenqua.com/shaj/)により実現し た。 52 図 6.4 起動後認証画面 6.3.3.4. データ送信機能 データ送信時に使用する。 1）送信先となる宛先機関を選択 2）対象患者の情報（氏名、患者番号、生年月日）を入力 3）送信する情報種別を選択 4）対象データを画面入力または、既存ファイルより選択 5）送信対象として追加 6）1∼5 をデータ数分繰り返す 7）送信する 53 という操作によって、送信先機関向けのデータが、送信先機関向けに 暗号化されて、ハブセンターのサーバにアップロードされる。と同時に、 入力した患者情報、およびアップロードしたファイルの情報がセンター のデータベースサーバ内の「送受信履歴」テーブルに書き込まれ、各機 関での送信履歴や受信一覧画面の検索用として参照される。 選択できる情報種別としては、 1）診療情報提供書(データ入力) 2）検体検査結果(データ入力) 3）画像検査結果 4）その他文書(PDF) が指定可能であり、このうちデータ入力と記載のあるものについては、 クライアントアプリケーションでデータ入力画面が展開する。画像検査 については DICOM 画像ファイルを、その他文書(PDF)については PDF ファイルを選択するダイアログが表示される。 6.3.3.5. データ入力機能 上記のデータ送信種別において、診療情報提供書・検体検査結果など のデータ入力用種別を選択した場合、専用の入力画面が展開する。 必要な項目を入力し保存操作を行うことにより、HL7 CDA Release2 に準拠した XML ファイルが作成され、送信データ一覧に追加される。入 力画面の一例を図 6.5 に示す。 54 図 6.5 データ入力画面の例 6.3.3.6. 送信履歴検索・削除機能 過去に自機関から送信した診療データを、送信日、送信先、患者名に より検索・一覧表示する機能を持たせる。検索には、データベースサー バの一覧表示されたデータを選択し、削除する機能も同画面内で実現し た。概観を図 6.6 に示す。 55 図 6.6 送信データ履歴画面 6.3.3.7. 受信データ検索・表示機能 自機関あてに送信された診療データを、送信日・送信元機関・患者氏 名・情報種別により検索する機能、および検索結果一覧から必要な受信 データを選択して表示する機能を実装した。受信データ検索画面の例を 図 6.7 に示す。 本検索時にも、データベースサーバ上の「送受信履歴」テーブルを使 用する。 56 図 6.7 受信データ検索画面 6.3.3.8. 受信データ表示機能 受信データ検索結果一覧から必要な診療データを選択し表示操作を行 うことにより、個々の受信データ内のファイル一覧を表示する画面を展 開する。一つの受信データに含まれるファイルのリストが表示され、各 ファイルを選択することにより、内容を参照することが可能となる。 受信データ検索結果一覧から本ファイル内容が表示されるまでには、 ハブセンターサーバからの当該データのダウンロード、およびデータの 復号化処理が行われる。これらについては後述する。 受信データに含まれる可能性のあるファイルとしては、前述のデータ 入力画面より作成した XML ファイル、既存ファイルより選択した画像検 57 査の DICOM ファイル、既存ファイルより選択した PDF ファイルがある。 これらのうち、PDF ファイルを選択した場合には、クライアント PC に インストールされた Adobe Reader が起動されて内容を表示する。それ以 外の場合、そのままの形式では見読が困難な場合が予想されるため、XML ファイルについては PDF へ、DICOM ファイルについては JPG 形式へ 変換する機能を内蔵した。XML から PDF への変換機能については、 JasperReport （http://jasperforge.org/plugins/project/project_home.php?group_id=1 02）、DICOM から JPG への変換については、 dcm4che(http://www.dcm4che.org/)の各ライブラリを利用した。 図 6.8 受信ファイル一覧画面 58 6.3.3.9. 救急診療向け基礎情報登録機能 各医療機関において患者の同意のもとにあらかじめ救急診療に必要な 基礎情報を登録するインターフェイスを提供する。上述のデータ入力用 画面と同じく専用の入力画面を用意し、患者情報・アレルギー情報・直 近の処方情報・診療対象病名・留意事項を入力する。 入力した情報をもとに、データ送信時と同様に HL7 CDA Release2 準 拠の XML ファイルを作成し、データ送信時と同様の手順で暗号化後にハ ブセンターサーバにアップロードする。ただし、ここで暗号化に用いる 公開鍵は、特定の実在機関ではなく、救急診療用基礎情報登録用に仮想 的に作成した機関用の公開鍵を用いることとした。したがって、復号化 するためには、本公開鍵と対になる私有鍵が必要であるが、これはセン ターサーバ内の特定の場所に保持しておく。 6.3.3.10. 救急診療向け基礎情報参照機能 救急診療向けに登録された基礎情報は、クライアント側設定ファイル により許可された端末のみが参照可能な構成とした。参照時は、受信デ ータ参照と同じく、患者氏名・生年月日・登録元の患者番号により検索 し、検索結果から必要なデータを選択し表示する。 この時、サーバ内のデータは救急診療向け基礎情報登録用の公開鍵で 暗号化された状態にあり、対象データをいったんペアとなる秘密鍵で復 号化した後に、参照依頼元機関の公開鍵で再度暗号化してダウンロード 処理を行う。ダウンロードされた暗号化データは、通常の手順で自機関 の秘密鍵で復号可能であり、以後の処理は上述の受信データ参照と同じ である。なお、受信データ参照と同じく、送受信履歴が記録されるので、 59 いつ・どの機関が当該データを復号・参照したかが追跡可能である。 6.3.3.11. 患者同意書登録機能 救急診療向け基礎情報登録等、患者に対し個別の同意が必要な場合、 同意書のスキャン文書を本アプリケーション内でハブセンターに登録す るインターフェイスを提供する。画面の概観を図 6.9 に示す。同意書を登 録する機関での患者番号と氏名、生年月日を指定し、スキャンされた同 意書を選択して登録を行う。入力された情報をもとに、データベースサ ーバ内の「同意書データ」テーブルに情報を格納し、診療データ送信時 および救急基礎情報登録時に同意書の有無をチェックする。 図 6.9 同意書登録画面 60 6.3.3.12. 患者認証情報登録機能 後述する患者向けの Web(JSP)アプリケーションで使用する認証情報 と、自機関の情報および患者番号と関連づける。本実証実験においては、 患者向け Web アプリケーションで使用する認証情報は事前に発番してお き、各医療機関に事前配布する運用を想定する。患者の通院する医療機 関で患者の希望にしたがって、認証情報を手渡すとともに、本登録機能 を用いて、当該患者の通院する機関情報・患者番号と患者向けアプリケ ーションで使用する認証 ID を紐づけ、データベースサーバ内の「患者認 証マスタ」テーブルに保持する。 図 6.10 患者認証情報登録画面 61 6.3.3.13. 暗号化・復号化機能 本アプリケーションで扱う診療情報データは、医療機関からハブセン ターにアップロードする前に暗号化を行い、参照側の機関でダウンロー ド後に復号化するルールを厳守する。 暗号化には、S/MIME 方式による暗号化を採用し、送信先機関のみが 復号可能な構造をとる。以下、暗号化・復号化に係る手順・実装につい て記載する。 まずはじめにこれまで記載した診療データのアップロード・ダウンロ ードに関しては、一定のファイル配置を規定する。 一回の送受信データは、フォルダを ZIP 化した 1 ファイルを対象とし、 ファイル名は、送信元機関識別 ID(10 桁)+送信日時 (YYYYMMDDhhmmss).zip とする。 フォルダ内にインデックスファイル(index.xml)とデータ格納フォルダ (DATA)を用意する。インデックスファイルには、表 6.1 のように、送信 日・送信時刻・送信元機関番号・送信先機関番号・患者情報(患者 ID､氏 名､生年月日)・データファイル数・ファイル名・データ種別などを記載し、 各々のデータファイルは格納フォルダに配置する。 表 6.1 インデックスファイルの例 <?xml version="1.0" encoding="UTF-8"?> <index xmlns="http://mscz.h.u-tokyo.ac.jp/2009" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="http://mscz.h.u-tokyo.ac.jp/2009/XSD/index.xsd"> <sendDate value="20100316"/> <sendTime value="090406"/> 62 <sender> </sender> <receiver> </receiver> <patient> <id extension="1310629717" root="1.2.392.200250.2.2.1"/> <id extension="1399999999" root="1.2.392.200250.2.2.1"/> <id extension="takahashi0003" root="1.2.392.200250.3.3.1"/> <name family="東大" first="太郎"/> <dateOfBirth value="19610325"/> </patient> <sendData> <sendFile fileName="131062971720100316090406.zip"/> <innerFileCount value="1"/> <innerFile beforeName="E131062971720100316090406.xml" fileName="E131062971720100316090406.xml" infoType="E"/> </sendData> <userID value="medicinf"/> </index> 圧縮された ZIP ファイルに対して、S/MIME 方式の暗号化処理を行う。 ZIP ファイルを Base64 エンコードし、送信元の秘密鍵による SHA-1 アルゴリズムによる署名、送信先の公開鍵による AES128 ビット暗号を 施す。 受信側では逆の操作を行い、暗号化されたファイルを自分の秘密鍵で 復号化して得られた署名付きの SignedData を検証し、データの改ざん がないことを確認する。 一連の処理にエラーがなければ、得られた ZIP ファイルを解凍し、送 信前のフォルダ以下のインデックスファイルおよびデータ格納フォルダ 63 以下のファイル群を獲得する。 本アプリケーションでは、一連の暗号化・復号化処理には、Bouncy Castle Crypt APIs for Java (http://www.bouncycastle.org/)を使用した。 送信先の公開鍵は、機関識別番号を指定して、ハブセンターのアプリ ケーションサーバに SOAP によるリクエストを投げ、アプリケーション サーバが後述する公開鍵ディレクトリサーバから公開鍵を入手し、クラ イアントに SOAP レスポンスとして返す構造とした。 6.3.3.14. その他機能 1）メール通知機能 診療データのアップロード完了時に、送信先機関属性情報として登録 されたメールアドレスに、データ送信があったことを通知する機能を設 けた。図 6.11 参照。 また、医療機関による受信の際に、当該患者に対する認証 ID およびメ ールアドレスが登録されていれば、同様に患者宛にデータ参照があった 旨の通知メールを送付する機能を設けた。 2）データ消去機能 不用意な診療データファイルの流出を避けるため、クライアントアプ リケーション終了時には、解凍したファイルを含め、使用した受信ファ イルを削除する機能を設けた。 3）利用機関登録機能 ハブセンターサービス管理者向けにアプリケーション内部で使用する 機関属性情報を登録する機能を設けた。機関識別番号・機関名称・住所・ 電話番号・メールアドレスなど、本アプリケーション内部で必要となる 64 情報を登録するインターフェイスを提供する。 図 6.11 医療機関向け送信通知メールサンプル 65 6.3.4. データベース これまでの各種機能を実現するために、ハブセンターデータベースサ ーバ上に以下のようなテーブルを実装し、サーバおよびクライアントア プリケーション上で利用する。 表 6.2 データベース・テーブル一覧 テーブル名称 概要 利用機関の属性情報 機関マスタ 機関番号、名称、住所、メールアドレスなどを 格納する 送受信で扱う情報種別マスタ 情報種別マスタ 診療情報提供書、画像検査情報などの情報種別 をコード化して格納する 患者認証マスタ 患者認証データ 患者向け認証 ID とパスワードを格納する 患者向け認証 ID と医療機関番号・患者番号の対 応情報を格納する 患者の同意書ファイル管理情報 同意書データ ファイルの実態はファイルシステム上に保管す る ファイルの送信／受信履歴データ 検索・表示用に、患者情報、送信先/送信元機関 送受信履歴データ 番号、送信日時、未読・既読状態などを格 納する。 個々の送信データに含まれるの情報種別毎の数 送信データ情報種別データ を格納する サーバ上の個々の保持データに関しての参照履 受信既読データ 歴を格納する 66 6.3.5. 患者向けアプリケーション 診療情報連携向けアプリケーションを使用して、医療機関等の間で交 換された履歴を患者が参照する機能を提供する。サーバハードウェアは、 診療情報連携向けアプリケーションと同じ構成とし、患者が Web ブラウ ザにより利用するための、JSP サービスを SSL 上に実装した。データベ ースサーバは、上述の診療情報連携向けアプリケーションで使用するテ ーブルの一部を利用する。本アプリケーションでは、 認証機能 送受信データ履歴一覧機能 削除依頼申請機能 メールアドレス登録・変更機能 同意書の撤回機能 の機能を実現した。個々の機能についての詳細は以下に記す。 6.3.5.1. 認証機能 患者が本アプリケーションを利用するための URL や認証情報(ID、パス ワード)は、医療機関での同意書登録と引き換えに配布される運用を想定す る。指定された URL にアクセスし、配布された ID、パスワードを入力す ることにより、アプリケーション機能が利用可能となる。一つの患者向け 認証情報に対して、複数の医療機関・患者番号のセットを対応させること が可能な構成とした。 67 6.3.5.2. 送受信データ履歴一覧機能 診療情報連携向けアプリケーションで医療機関等の間で送受信された患 者自身の診療データおよび救急診療向け基礎情報の状態を閲覧することが 可能である。送信日時、送信元機関、送信先機関、情報種別と未読/既読の 状態を一覧することができる。一覧画面のサンプルを図 6.12 に示す。 図 6.12 患者向けデータ一覧画面 6.3.5.3. 削除依頼申請機能 図 6.13 の診療データ一覧画面内で削除したいデータを選択し、削除依頼 ボタンを押下することにより、当該データの登録元機関に対して削除依頼 68 を通知する機能を設けた。 削除依頼がなされた診療データは、状態を「削除依頼済」として、送受 信データ履歴テーブルの情報を更新する。登録元の医療機関で当該データ が削除操作された場合には、状態は「削除済」に変更する。図 6.13 参照。 図 6.13 削除依頼後の画面サンプル 6.3.5.4. メールアドレス登録・変更機能 患者自身のメールアドレスは、ログイン時にチェックされて、登録が 無い場合は入力画面へと誘導する。また、登録されているメールアドレ スは随時変更が可能である。 診療情報連携向けアプリケーションで、救急診療向けの基礎情報デー タが受信・参照された場合には、登録されているメールアドレスに対し 69 て、参照された旨の通知が行われる。 6.3.5.5. 同意書撤回機能 医療機関において登録された同意書を一覧し、目的の同意書を選択し て撤回する機能を提供する。図 6.14 参照。 同意書が撤回された場合、該当の医療機関から登録された診療デー タ・救急診療向け基礎情報に対し、前述の削除操作と同様の削除処理が 行われ、診療情報連携向けアプリケーションから当該データの参照が不 可能となる。 図 6.14 同意書撤回画面サンプル 70 6.3.6. 公開鍵ディレクトリサービス 6.3.6.1. 認証局システム 診療情報連携向けアプリケーションにおいて、クライアントからのサーバ SOAP サービス利用時の SSL クライアント認証、および診療データの暗号化 に用いる医療機関向けの鍵ペアは、ハブセンターに専用のプライベート CA を構築し、電子証明書の発行を行った。システムソフトウェアには、Verisign 社の「マネージド PKI マルチプロダクション」を用いた。OS は、Red Hat Enterprise Linux 5.3、アプリケーションサーバは、Apache2.2.3 を使用した。 電子証明書および認証局システムには以下の機能を実現し、電子証明 書の発行・失効などの電子証明書の管理操作はハブセンター管理者が行 うことを想定する。 参加機関向けの電子証明書は構築する独自認証局から直接発行された 階層とする。 電子証明書形式は、X.509v3 形式とする。 認証局証明書、電子証明書とも署名アルゴリズムは、SHA-1、鍵生成 長は 2048bit とする。 利用者証明書の失効は、v2 形式の CRL で生成し、1 日 1 回更新する。 生成した CRL を http リポジトリへ公開し、センターサーバから取得 可能とする。 電子証明書の新規申請、取得、検索、失効、更新操作を可能とする。 管理者向けサイトは、専用の電子証明書により、認証された管理者の みに制限する。 有効な電子証明書の一覧を LDIF 形式でエクスポート可能とする。 71 6.3.6.2. 電子証明書の仕様 認証局証明書、CRL、および参加機関向けの証明書の仕様を表 6.3∼6.5 に示す。 認証局は本実証実験用の独自 CA を構築し、記載のとおりの名称とし た。 CRL は、診療情報連携アプリケーションの SOAP サービスを利用する 際に、参加機関側のクライアント証明書の有効性を検証するために、ア プリケーションサーバ上の Apache Tomcat に設定して使用する。また、 CRL は一日一回、自動で認証局システムよりダウンロードする仕様とし た。 参加機関向けの証明書内には、最低限の情報として、 「機関の英語名称」、 「機関コード(10 桁)」を、それぞれ、Common Name(cn)、Organization Unit(ou)部に記載する。 表 6.3 認証局証明書の仕様 c = JP 名称 o = MIC Special Cyber Zone Project by UT cn = MIC Special Cyber Zone Project CA by UT 鍵アルゴリズ ム・鍵長 署名アルゴリ ズム RSAEncryption 2048bit SHA1WithRSAEncryption 有効期間 10 年間 鍵使用用途 keyCertSign, cRLSign 基本制約 ca=True pathLen=0 72 表 6.4 CRL の仕様 有効期間 4 日間、一日一回生成する 署名アルゴリズム SHA1WithRSAEncryption 表 6.5 参加機関向け証明書の仕様 0 = MIC Special Cyber Zone Project by UT(固定) OU = MIC Special Cyber Zone Project CA by UT(固定) Subject 記載事項 C = JP(固定) OU = FacilityCode ‒ 10 桁の機関コード CN = 機関の英語名称 鍵アルゴリズム・ 鍵長 RSAEncryption 2048bit 署名アルゴリズム SHA1WithRSAEncryption 有効期間 1 年間 鍵使用用途 digitalSignature, keyEncipherment 基本制約 ca=false 6.3.6.3. ディレクトリサービスとの連携 診療情報連携向けアプリケーションにおいて、診療データの暗号化の際に 使用する公開鍵は、送信先を選択後に後述する公開鍵ディレクトリサービス から取得する。認証局システムは、現在有効な機関向け証明書の一覧をエク スポート可能なように LDIF(LDAP data interchange format)形式で電子フ ァイルとして取り出す機能を持たせる。 参加機関の登録・削除の際は、ハブセンター管理者が、認証局システムを 使用して、機関向けの証明書操作を行い、必要な場合は、LDIF ファイルを作 成して、ディレクトリサービスにインポートする運用とした。LDIF ファイル 73 のサンプルを表 6.6 に示す。 表 6.6 LDIF ファイルのサンプル dn: cn=The University of Tokyo Hospital,ou=FacilityCode - 1318814790,ou=MIC Special Cyber Zone Project CA by UT,o=MIC Special Cyber Zone Project by UT,c=JP cn:The University of Tokyo Hospital ou:FacilityCode - 1318814790 ou:MIC Special Cyber Zone Project CA by UT o:MIC Special Cyber Zone Project by UT c:JP usercertificate;binary::MIIElzCCA3+gAwIBAgIQGI3Ve4iJT/DDY1 (中略) zNgCDaInoaDkjHwT2BoBREeIqCGuZ6J3Jtqm objectclass: subscriber 6.3.6.4. 公開鍵ディレクトリサーバー 診療情報向けアプリケーションでクライアントから要求された送信先 機関の公開鍵を検索・取得可能なインターフェイスを LDAP により実装 した。認証局システムから出力される LDIF ファイルを、LDAP サーバ にインポートして機関向け証明書の登録・削除を行う。 前述の LDIF フォーマットにおいて、検索時には、機関コード(ou 部) を用い、レスポンスとして、usercertificate 部分を返すことにより、対象 機関の公開鍵が取得可能な実装とした。 また、ディレクトリサービスは以下の実行環境において構築した。 実行環境 OS： RedHat Linux Ver. 5.3 74 LDAP サーバ： OpenLDAP 2.3.43 6.3.7. 調剤実施情報連携向けアプリケーション 診療情報連携向けアプリケーションでは、1 回のデータ送信について、1 患 者分のデータのみを含めることを前提とした仕様であるが、調剤薬局側で作 成される調剤実施情報提供書は、定期的に薬局側のレセコンシステムから出 力される運用が現実的で、その場合対象となる調剤実施情報は複数医療機関 にわたる複数の患者のデータを扱う必要がある。このため、調剤実施情報連 携アプリケーションでは、特に調剤薬局側でのアップロードファイル作成、 センターサーバへのアップロードに係る処理で上述の診療情報連携とは異な る機能を実現する必要がある。 本実証実験では、以下の操作フローを前提として、ハブセンターサービス の実現を行った。 １）調剤薬局側レセコンから出力される HL7 CDA Release2 準拠の XML 形式の調剤実施情報提供書をひとつのフォルダに送信枚数分配置 する。 ２）出力された電子ファイルを専用の暗号化ツールを用いてアップロ ード用のアーカイブファイルを作成する。暗号化ツールでは、返送先医 療機関単位のフォルダに振分けを行い、各フォルダごとに圧縮、暗号化 を施した上で、さらに全体を一つのアーカイブにまとめる。 ３）ハブセンターサーバの Web サービスにアクセスし、調剤薬局側か ら作成したアーカイブのアップロードを行う。 ４）センターサーバは、アップロードされたアーカイブファイルを展 開し、送信先医療機関ごとの圧縮ファイルを抽出後、アーカイブ内に含 まれる各送信先医療機関ごとに受信データを登録する。 75 ５）調剤実施情報を受信する医療機関は同様にハブセンターサーバの Web サービスにアクセスし、受信データ一覧を参照し、必要な調剤実施 情報提供書データをダウンロードする。 ６）圧縮ファイルをダウンロード後に、復号化ツールにより復号・解 凍し、調剤実施情報提供書のファイル群を取得する。 送信対象となる調剤実施情報提供書 XML ファイルは、調剤薬局側のレセ コンシステムベンダーに、XML ファイルの規格書を配布、出力機能を実 装してもらった。 暗号化ツールは各調剤薬局に配布し、本実証実験では、手動で実行し てもらう運用とした。調剤実施情報連携におけるフローの概要を図 6.15 に示す。 図 6.15 調剤実施情報連携の処理フロー 76 6.3.8. 実行環境 調剤実施情報連携を実装した環境は以下のとおりである。クライアン トについては、動作検証済みの環境のみの記載である。 サーバ OS： RedHat Linux Ver. 5.2 Web サーバ： Apache 2.2.11 アプリケーションサーバ：Apache Tomcat 6.0.18 DBMS： PostgreSQL 8.3 JAVA： JDK(JRE) 1.6.0 クライアント OS： Microsoft Windows XP Microsoft Windows Vista Turbolinux Client 2008 Live Edition ブラウザ： Internet Explorer 6 Internet Explorer 7 Internet Explorer 8 Fire Fox 3 6.3.9. 暗号化ツール 調剤実施情報提供書を提出用にアーカイブする暗号化ツールは参加調剤薬 局に対して事前に配布した。ツール自体は C 言語で開発し、Windows OS, Linux OS での実行を可能とした。 本調剤実施情報連携システムおよび、暗号化ツールの使用にあたり、取り 77 扱う調剤実施情報提供書のデータファイルには表 6.7 に示すファイル命名規 約を設けた。調剤薬局番号や医療機関番号は、診療情報連携で使用した機関 番号と同じ規則にしたがって数字 10 桁で表現する。暗号化ツールでは、この うち医療機関番号の部分を識別して、返送先となる医療機関ごとのフォルダ を作成し、機関単位に対象データファイルを振分ける。診療情報連携の場合 と同様に各医療機関ごとのフォルダには、最上位に XML 形式の交換用基本情 報ファイルがツールにより作成され、表 6.8 に示すように、作成日、薬局番号、 ファイル数の情報が記載される。 各医療機関ごとに振り分けられたフォルダは、オプション指定により、各 医療機関の公開鍵で圧縮・暗号化することが可能であり、最終的なアップロ ード用ファイルは、本暗号化ツールにより、全体を圧縮した上でセンターWeb サーバの SSL 証明書の公開鍵で暗号化される。表 6.9 参照。 最終的なアップロード用ファイルは、 <調剤薬局番号：10 桁>_<作成日：8 桁>_<同日内送信回数：1 桁>.zip という一つの暗号化された ZIP ファイルとし、これを 1 回の送信ファイル として、調剤薬局側から Web 画面より選択し、アップロードする。 表 6.7 調剤実施情報データファイル命名規約 開始 長さ 内容 フォーマット 1 1 p 2 10 調剤薬局番号 数字 10 桁 12 10 医療機関番号 数字 10 桁 22 8 ファイル生成日 30 1 31 6 位置 固定文字 同日内送信回数(分割送信の場合)。 0 から順に増加させる 同一フォルダ内で重複しな いための識別番号 78 YYYYMMDD 数字 1 桁 数字 6 桁 37 .xml (拡張子) 4 固定 表 6.8 交換用基本情報ファイル <?xml version="1.0" encoding="UTF-8"?> <index xmlns="http://*****/preparationOfDrugs/2008" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://*****/preparationOfDrugs/2008 ./XSD/ix08_V0 8.xsd"> <!-- 作成年月日（2008 年 8 月 20 日） --> <creationTime value="20080820"/> <!-- 送付元機関（調剤薬局番号：1234567890 の場合） --> <sender> <id root="1.2.392.200250.2.2.1" extension="1234567890"/> </sender> <!-- 総ファイル数 (「5」の場合) --> <totalRecordCount value=“5"/> </index> 表 6.9 医療機関ごとの暗号化・圧縮後のレイアウト (圧縮後) 0123456789_20080820_0 (調剤薬局 A) ├─ 交換用基本情報 XML ファイル ├─ (医療機関 X) │ ├─ 交換用基本情報 XML ファイル │ └─ 0123456789_20080820_0.zip └─ (医療機関 Y) ├─ 交換用基本情報 XML ファイル └─ 0123456789_20080820_0.zip 79 6.3.10. 調剤実施情報集配信 Web サーバ ハブセンターに設置した調剤実施情報の集配信 Web サーバは、SSL サ ーバとして稼働させ、医療機関および調剤薬局からは、認証成功後に利 用可能とした。 調剤薬局側の操作画面の概観を図 6.16 に、医療機関側の操作画面の概 観を図 6.17 に示す。 図 6.16 調剤薬局向け操作画面 80 図 6.17 医療機関向け操作画面 調剤薬局側の画面では、 1）暗号化ツールを用いて作成したアーカイブファイルを指定してアッ プロードする機能 2）過去のアーカイブファイルの送信履歴一覧機能 を実現した。 送信履歴一覧では、送信日時、ファイル名、登録状態、アーカイブ内 の調剤実施情報提供書ファイルの件数を表示する。 一方、医療機関側の画面では、各参加薬局から送信・登録されたアー カイブファイルが時系列に一覧表示され、送信日時、ファイル名ととも に、アーカイブ内の調剤実施情報提供書ファイルの件数が確認できる。 81 表示されたファイル名をクリックすることにより、自機関あての暗号化 されたアーカイブファイルをローカル PC 内にダウンロードする。 医療機関側では、アーカイブファイルダウンロード後に別途配布した 復号化ツールにより、アーカイブファイルの復号化・解凍を行い、調剤 実施情報提供書を取得する。 6.4. セキュリティーに関する方針 診療情報に係る情報システムにおける一般的な技術的対策として、以 下の安全対策を講じる必要があるとされている。本実証実験におけるハ ブセンター・システムと照合しながら記載する。 6.4.1. 利用者の識別及び認証 本実証実験では、PKI による参加機関の認証識別と、利用者のクライ アント PC 上でのパスワードチェックを併用する。電子証明書の利用に関 しては、遺失・盗難等による事故発生時には、センター管理者に届け出 を行い、該当する証明書を失効させることが必要となる。一方で、クラ イアント PC 上のアカウントについては、通常の診療情報システムと同様 に不正使用がないように適切に管理されるべきである。 6.4.2. 情報の区分管理とアクセス権限の管理 本実証実験で扱う診療データは、各医療機関等において無制限に閲覧 できるものではなく、適切なアクセス権限を設定する必要がある。救急 診療用の基礎情報に関しては、医療機関の通常部門と救急診療部門に異 なる権限を設定し、閲覧権限を区別する。また、医療機関、調剤薬局で 82 も利用できるサービスに区別が必要である。本実証実験では、機関マス タないしは、アプリケーション設定にて、機関種別を識別し、利用でき るメニュー等の制御を行うこととした。 ハブセンターサーバ管理者が、診療データを無制限に参照できるよう な機能は持たせず、あくまで患者および送信元機関による診療データの 管理を基本とする。非常的措置として、直接データベースシステムを操 作して、不都合のある診療データのエントリを修正・削除することは可 能である。 6.4.3. アクセスの記録（アクセスログ） 診療情報データへのアクセスおよび操作履歴はすべてログファイルに 記録する仕様とした。とくに前述のとおり、暗号化された診療データの ダウンロード・復号操作の履歴はデータベースサーバ上に記録を保持す るとともに、対象患者に対して通知する機能も実現した。 6.4.4. 不正ソフトウェア対策 ウィルス対策ソフトの導入は必須であり、導入された状態でアプリケ ーションが正常に機能するように実装すべきである。本実証実験システ ムでは、 Java アプリケーションおよび Web アプリケーションを扱うが、 OS およびウィルス対策ソフトが常に最新化された状態でアプリケーシ ョンが機能する状態を維持すべきである。 6.4.5. ネットワーク上からの不正アクセス ハブセンターサーバは、インターネットにオープンなサービスとそう 83 でないサービスに区分し、FireWall によるアクセス制限を設けた。特に 専ら医療機関等がアクセスし、クライアント環境をある程度規定可能な 場合には、VPN 接続による暗号化された回線上でのアプリケーション使 用を原則とし、患者等がアクセスするインターフェイスは、クライアン ト側の環境を規定困難と考え、インターネットにオープンなものとする が、SSL 上での Web サービス等、最低限の暗号化されたサービスとして 実施する。ただし、本実証実験のアプリケーションにおいては、未暗号 のまま診療データをネットワーク回線上に送出することはしない。 さらに、本実証実験システムでは、医療機関等の外部に診療に係る患 者個人のデータを一時的にせよ保存することになる。医療機関が外部と 診療データを送受する場合には以下のような危険性を考慮する必要があ り、対策を講じるべきとされる。 6.4.6. 「盗聴」の危険性に対する対応 万が一、伝送途中で情報が盗み取られたり、意図しない情報漏えいや 誤送信等が発生した場合でも、診療データを保護するために適切な処置 を取る必要がある。本ハブセンターのアプリケーションにおいては、対 象となる診療データは送信元機関から外部へ出る前に適切に暗号化され、 送信先機関での受信後にはじめて復号化されるように設計・実装し、オ ブジェクトセキュリティを担保した。 6.4.7. 「改ざん」の危険性への対応 ネットワーク経路上での改ざん防止には電子署名が有効とされる。本 実証実験システムでは、送信データの作成の際に、S/MIME 署名と暗号 化を併用することにより、データの改ざんが検出できる機構を取り込ん 84 だ。 6.4.8. 「なりすまし」の危険性への対応 基本的な対策は、公開鍵基盤により実装する。アプリケーションを使 用するための機関証明書の検証、および S/MIME による暗号化データに 送信者の公開鍵を含めるなど、既存技術における最低限の識別機能の実 現は必要であり、本実証実験システム上に実現した。 また、本実証実験におけるハブセンターは医療機関から見れば、第三 者機関に相当し、診療情報連携以外の目的で、ハブセンターのサービス 事業者が独自に分析、解析等を行うことは医療機関等及び患者の同意が ない限り許されない。基本的には、サービス事業者に対して、医療機関 等はそれらが実施されないことの確認、もしくは実施させないことを明 記した契約書等を取り交わす必要がある。技術的な方法としては、例え ばトラブル発生時のデータ修復作業等緊急時の対応を除き、原則として 医療機関等のみがデータ内容を閲覧できることを担保することや、保存 される個人識別に係る情報の暗号化を行ったり、事業者の管理者といえ ども通常はアクセスできない制御機構をもたせることも考えられる。本 ハブセンターに保管される診療データはすべて受取先医療機関以外から は復号化不可能な暗号化がほどこされており、一定の情報保護対策を施 された状態と考える。 6.5. 地域医療情報連携ハブの運用ルール 1）設置場所 ハブセンターは、特定の医療機関からネットワーク経路上は独立した 85 位置に設置する。今回の実証実験では、東大病院内に設置されているが、 ネットワーク経路上は東大病院のネットワークの外部に位置しており、 東大病院の情報システムから独立している。 2）利用する医療機関の登録 医療情報連携ハブセンターを利用する医療機関は、事前に 10 桁の医療 機関番号（都道府県番号 2 桁＋1＋7 桁保険医療機関番号）と医療機関名、 連絡先メールアドレスなど登録に必要な情報をセンターに提供し、事前 に登録を行う。センターでは、公開鍵・秘密鍵ペアを発行し、秘密鍵フ ァイルを医療機関は送信用パソコンにセットアップする。利用医療機関 として登録する機関は原則として、受信可能な医療機関としても登録す る。これにより、参画する医療機関同士で安全な暗号化したファイルの 交換が可能となる。 3）利用する医療機関では、登録したメールアドレスに届く受信メール を 1 営業日以内に必ず読む運用ルールを守ることが必要である。 4）利用を廃止する医療機関の取扱い 医療情報連携ハブセンターに登録されている医療機関が、利用を廃止 する場合には、廃止届けを出して受信ができない状態にする必要がある。 6.6. 実施体制 本実証実験は、国立大学法人東京大学政策ビジョン研究センター（セ ンター長・教授：森田朗、教授：秋山昌範、他）を契約担当とし、ハブ センターの構築および運用に関する実証実験ならびに報告書作成は東京 大学医学部附属病院企画情報運営部（教授：大江和彦、助教：田中勝弥） により行われた。 86 主要なシステム開発は、データ・マネージメント株式会社（東京都港 区新橋 3 丁目 4 番 12 号）のシステムエンジニアグループにより行われた。 また診療情報に関連した XML 規格仕様書の作成の一部は、株式会社ケー アイエス（東京都中央区日本橋蛎殻町 1-36-7）に委託して実施された。 さらに、調剤薬局との情報連携サーバシステムについては、新日鉄ソリ ューションズ株式会社により開発されたシステムを使用した。 実証実験では、参考資料に示す 5 診療所および東京大学医学部附属病 院で医療機関相互における情報配送実験を、また調剤薬局および調剤レ セプトベンダーとして、日本調剤お茶の水中央薬局、日生薬局千駄木店、 セントラル薬局湯島店、水野薬局、にしすが水野薬局、赤門水野薬 局、竹内調剤薬局、好仁会薬局、日本調剤㈱、㈱EM システムズ、 ㈱日本メディコム、三菱電機インフォーメーションテクノロジー㈱、 サンヨー電機㈱、㈱デンソーウエーブが実証実験期間中に実験に参 画または協力し、調剤レセプトベンダーとりまとめ会社として、㈱クラ ヤ三星堂が協力した。 87 7. 実験の結果 7.1. 診療所と情報連携実験 本実証実験に参画した診療所は、5 機関である。各診療所からは 2010 年 3 月上旬に、診療情報提供書（匿名化したもの、ダミー作成したもの、 東大病院に括弧に患者の了解をもとに紹介するために作成したもののい ずれか）をＰＤＦファイル化して本実証実験の医療情報連携ハブセンタ ーへ送信してもらった。送信件数は、表 7．1 の通り、5 診療所からの 21 人分、ファイル数で 32 件であった。 各診療所ではいずれも、環境を整えた専用のノートパソコンとＡ4 型コ ンパクトスキャナのセットを貸出し、マニュアルにもとづいて説明した 後、実際に医師または事務職員が操作してハブセンターに送信した。 いずれに診療所でも電子カルテシステムが稼働しており、電子カルテ システムで作成した診療情報提供書や検査結果伝票を、印刷してスキャ ナで取込んで送信したケースと、電子カルテシステムで作成してＰＤＦ ファイル形式でサーバに保存後に、そのサーバ上のフォルダをネットワ ーク越しにオープンして送信したケースがあった。 またネットワーク環境として、NTT b-Mobile によりダイアアップイン ターネット接続で送信した診療所と、既設のインターネット回線に接続 して送信したケースの両方があった。 いずれの診療所においても、またいずれの接続形態においても、問題 なく実証実験が実施でき、正常にかつ容易にファイルを送信できること が確認できた。 88 表 7．1 診療所からのデータの送信実験の内訳 ファイル 送信日時 医療機関番号 医療機関名 送信件数 2010.3.23 14:16 1410504639 上六ツ川内科クリニック 1 2010.3.23 14:15 1410504639 上六ツ川内科クリニック 1 2010.3.23 14:14 1410504639 上六ツ川内科クリニック 1 2010.3.03 13:02 1310527374 2010.3.09 11:45 1310629717 高橋医院桜木(健康会) 1 2010.3.09 11:48 1310629717 高橋医院桜木(健康会) 1 2010.3.09 13:49 1310437921 四谷内科(博由会) 1 2010.3.09 13:52 1310437921 四谷内科(博由会) 1 2010.3.09 13:55 1310437921 四谷内科(博由会) 1 2010.3.09 16:18 1310930545 ナグモクリニック(ナグモ会) 3 2010.3.09 16:25 1310930545 ナグモクリニック(ナグモ会) 1 2010.3.09 16:35 1310930545 ナグモクリニック(ナグモ会) 4 2010.3.09 16:41 1310930545 ナグモクリニック(ナグモ会) 3 2010.3.09 17:03 1310930545 ナグモクリニック(ナグモ会) 3 2010.3.09 17:07 1310930545 ナグモクリニック(ナグモ会) 3 2010.3.10 10:08 1310437921 四谷内科(博由会) 1 2010.3.10 10:10 1310437921 四谷内科(博由会) 1 2010.3.10 10:12 1310437921 四谷内科(博由会) 1 2010.3.10 12:20 1310437921 四谷内科(博由会) 1 2010.3.13 18:02 1310629717 高橋医院桜木(健康会) 1 2010.3.13 18:05 1310629717 高橋医院桜木(健康会) 1 合計 21 件 御茶ノ水聖橋クリニック(聖桐会) 5 診療所 1 32 また今回、対象としたデータは、診療情報提供書の内容に相当する診 療情報であり、救急診療用の実験登録データとしても仮想的に使用でき るものであった。そこで仮にこの患者が東大病院に救急患者として搬送 されたことを想定して、これらのデータを東大病院内の診療情報ネット ワーク上にあるパソコンからダウンロードし参照することができた。 89 7.2. 調剤薬局との情報連携実験 調剤薬局との調剤実施情報連携実験は、7 調剤薬局が参加し実験期間中 には 2 調剤薬局から合計 134 件の調剤実施情報の転送実験を実施するこ とができた。図 7．1 は、調剤実施情報を受信するハブセンター側の画面 である。この画面で件数の合計は 147 件となるが、このうち No.6 は実験 用のダミー調剤薬局ファイルであるため、この 12 件を減じて、実際の情 報受信件数は 134 件となる。 図 7．1 調剤実施情報の受信ハブセンター画面 図 7．1 において No.1 の受信ファイルをダウンロードしてアーカイブ を展開したフォルダの状態を図 7．2 に示す。先頭の ix08_V08 ファイル 90 が封筒に相当する共通情報ファイルであり、それ以外のファイルが調剤 実施情報を HL7-CDA 化したファイルであり、仕様通りに送受信が実現 できていることが確認できた。 図 7．2 受信したアーカイブを展開したフォルダ状況 91 8. 考察 8.1. 地域医療情報連携ハブのルールおよび運用条件について 本実験では、地域医療情報連携ハブを構築し、診療所および調剤薬局 から大学病院への情報中継実験を行った。以下ではこの結果を考察し、 必要なルールと運用条件について考察する。 8.1.1. 医療機関とハブとの間の安全確実な情報転送の確立 1） 通信路の暗号化 医療機関等からの地域医療情報連携ハブの利用においては、インター ネット VPN を用いた暗号化回線接続を基本とした。これは盗聴などの危 険への対策として通信回線自体の暗号化を実現するためである。さらに VPN 経路上で SSL 通信を行ってハブサーバと通信をする。調剤実施情報 連携向けのアプリケーションは、調剤薬局側の環境に制約がある場合が 多く、新たに VPN 接続を構築することが困難な場合が多い。今回は、SSL によるサービスとして実装した。 2） 登録機関のみのアクセス制限 VPN 接続を経由しないと本ハブのサービスには到達できない構成とす ることにより、あらかじめ登録した医療機関だけが通信路を確立できる 構成とした。これにより、第三者からの攻撃に対してより安全なサービ ス形態が実現できた。 3） 利用機関認証と利用者認証 VPN 経路を確立した上で、機関ごとに電子証明書を配布する公開会議 92 証明書により、ハブセンターへ接続時のクライアント認証を行う。これ により、参加登録機関であっても、公開鍵証明書をインストールしたコ ンピュータ以外からの不適切なアクセスを禁止することを実現した。参 加登録機関であればその機関内のどのコンピュータから情報を転送でき てもよいという考え方もある。しかし、紙の診療情報提供書の場合でも、 他の医療機関への情報提供は、医療機関内の医療者個人として行ってい るわけではなく、医療機関として情報提供しているのが普通である。ま た、病診連携部や医事係のように診療情報提供を他の医療機関に行う窓 口部署があるのが普通である。従って、今回は、医療機関内の任意のコ ンピュータから接続可能とするのではなく、特定のコンピュータに限定 して接続可能とした。どちらの運用とするかについては、実際には医療 機関ごとにポリシーが違っていてもよいと考えられ、ルール整備の際に 選択できるようにすべきであろう。 クライアント上の利用者認証機能は、アプリケーション起動時に利用 者を識別するための機能であり、クライアント PC 内に作成されたユーザ ID とパスワードを入力することによって、パスワードチェックを行い、 利用者が誰であるかを識別可能とする。利用者の登録は事前にセンター 側で行うが、今後、医療機関側で行えるようにするかどうかの検討が必 要であろう。 4） ハブセンターのサーバ認証 ハブセンターのサイトは、 SSL によるサーバ認証を可能とすることに より実現した。従って、VPN による通信経路確立後に、医療機関側から ハブに接続した場合に、ハブが正当なものであるかの証明の確認が恒常 的に実施される必要がある。 5） 医療機関ごとの診療情報の暗号化 送信医療機関側のアプリケーションでは、送信すべき情報をひとつの 93 ZIP ファイルに圧縮し、送信元機関の秘密鍵での署名の後に、送信先機 関の公開鍵による暗号化を施すようにした。これにより医療機関とハブ との相互間における伝送路がＶＰＮにより暗号化されている経路上で、 ハブに送信されるファイル自体が送信先医療機関でしか復号化できない 方法で暗号化されていることになる。この機能は、ハブを運営する機関 がハブを通過するデータを解読することができないという点で重要であ る。また、当然であるがハブを運営する機関は医療機関に秘密鍵と公開 鍵のペアを発行し配付する機関と独立した機関でなければならない。こ れはルール整備の上で重要なポイントとなる。 8.1.2. 医療機関側のセキュリティーポリシーとの整合性 医療機関では、①ＬＡＮを外部インターネットに全く接続していない ケース、②ＬＡＮをファイアーウオール経由でインターネットに接続し ているが、ＶＰＮ接続などを認めていないケース、③ＬＡＮをファイア ーウオール経由でインターネットに接続し、外部へのＶＰＮ接続が可能 なケース、がある。さらに③のケースでも、電子カルテのネットワーク とは接続していないケースもある。こうした様々なセキュリティーポリ シーの医療機関がある中で、本実証実験で構築した地域医療情報連携ハ ブへ接続して情報交換を可能とするには、インターネットへの接続経路 を複数用意する必要があった。 通常、診療所の規模では、他の医療機関に診療情報を伝送する必要が ある紹介患者数は、1 日に多くても数件以内であり、ほとんどの場合には 数日に 1 件程度である。従って、上記のケース①や②のような場合には、 新たな設備投資をして医療機関のセキュリティーポリシーに合致したイ ンターネット接続設備を導入するよりも、送信需要があった場合にだけ インターネットに接続できるオンデマンド接続環境があれば十分と考え られる。そこで、今回は、NTT b-Mobile によるダイアルアップ型 3Ｇ接 94 続を行えるように環境を構築した。 こうしたダイアルアップ型接続は、大量の医療画像情報を送受信する 際には通信速度が問題となるが、今回のように診療所側での送受信の場 合には、それほど大きなファイルサイズを送受信するニーズはあまりな く、数 100 キロバイトから 100 キロバイト程度のことが多いため、十分 実用になる。 調剤薬局では、ほぼ 100％オンラインレセプト処理を実施しているので、 インターネット接続を行っているところが多い。今回参画した調剤薬局 もすべてインターネット接続可能であった。しかし、レセプトコンピュ ータ専用のパソコン環境となっているケースがあり、かならずしも VPN クライアント環境を自由に構築できない場合が想定されたため、調剤薬 局からの接続は、6.3.2 節で述べたように VPN 接続ではなく、SSL によ る暗号通信路だけとした。 8.1.3. ハブでの情報転送の進捗状況の管理 過去に自機関から送信した診療データを、送信日、送信先、患者名に より検索・一覧表示する機能を持たせる。検索には、データベースサー バの一覧表示されたデータを選択し、削除する機能も同画面内で実現し た。この機能は、誤った診療情報を送信してしまった場合や、新たな情 報に差し替えたい場合に重要である。また、相手医療機関が読んだかど うかの状態を把握する必要があるため、診療上重要な機能である。今回 は実装していないが、一定期間以上未読である場合には、送信側医療機 関にそのことが通知される仕組みが必要がある。また、こうしたシステ ムを安全に運用するには、送受信のどこまでは送信側が責任をもち、ど こからは受信側の責任となるのかについてルールの策定が必要であると 考えられた。 95 また、自機関あてに送信された診療データを、送信日・送信元機関・ 患者氏名・情報種別により検索する機能、および検索結果一覧から必要 な受信データを選択して表示する機能を実装した。これは、受信時に一 度電子メールで受信通知が届いていることとは別に、ハブにアクセスし て受信状況を確認できる機能である。前述の送信側機能と関係するが、 一定期間受信していない情報が蓄積されている場合には、受信を促す仕 組みが必要であると考えられた。 8.1.4. 診療所との情報連携 今回、実証実験に参画した診療所はいずれも電子カルテシステムが運 用されており、診療情報提供書は電子カルテにより電子的に作成されて いた。また検査結果についても電子カルテで管理されていた。従って、 診療所クライアントアプリケーションを電子カルテシステムと簡単な方 法で連携するようにすれば、診療情報提供先を電子カルテシステムで選 択するだけで、その相手先がハブセンターに参画している医療機関であ るかどうかをチェックし、該当すれば自動的にハブセンターに送信する といった仕組みを構築することが可能であると考えられた。今回の実証 実験では、個々に異なる電子カルテシステムとの連携開発をする時間的 余裕と経費的余裕がなかったが、今後、共通インターフェイスを構築す ることにより、多くの既存の異なる電子カルテシステムと技術的に簡単 な方法で連携することができると考えられ、その実現は、診療所からの 電子的な診療情報送信の効率的な実施に貢献するであろう。 8.1.5. 調剤薬局との情報連携 今回の実証実験では、東大病院でこれまで調剤薬局およびそのレセプ トコンピュータベンダーとの共同研究で実施してきた仕様を活用して、 調剤実施情報の伝送を行った。その仕様では、各レセプトコンピュータ 96 内に HL7-CDA に準拠した調剤実施情報規格（XML 形式）にデータを変 換するソフトウエアを追加開発し、それにより生成される HL7-CDA 規 格データをアーカイブしてハブセンターに送信するものであった。今回 の実装実験にあたって再度調査したところ、すでに調剤薬局でのオンラ インレセプト実施率はほぼ 100％に達していることから、個々のレセプト コンピュータの改造をするよりも、オンラインレセプト出力ファイルか ら HL7-CDA 規格に変換して調剤薬局から送信するか、あるいはオンラ インレセプトファイルそのものをハブセンターに送信してもらい、セン ター側で標準規格に変換する手法のほうが、全国への普及が早いと考え られた。この場合、診療報酬請求情報であるレセプトファイルをハブセ ンター経由で送信することの妥当性を確保することが必要である。 8.1.6. 救急患者のための情報の取り扱い 今回実証実験で構築した救急診療用情報のハブセンターへの預託シス テムは、情報の利用目的を特化している点と、事前に予期しない医療機 関での利用を事前承認してデータを預ける仕組みである点が特徴である。 個人情報保護法および同法関連ガイドラインでは、医療機関は第三者提 供制限について例外として以下の記載がある。 利用目的による制限の例外 医療・介護関係事業者は、あらかじめ本人の同意を得ないで法第15条の規定により特定さ れた利用目的の達成に必要な範囲を超えて個人情報を取り扱ってはならないが（法第16条 第1項）、同条第3項に掲げる場合については、本人の同意を得る必要はない。具体的な例と しては以下のとおりである ②人の生命、身体又は財産の保護のために必要がある場合であって、本人の同意を得るこ とが困難であるとき （例） ・意識不明で身元不明の患者について、関係機関へ照会したり、家族又は関係者等からの 安否確認に対して必要な情報提供を行う場合 従って医療機関では、あらかじめ診療情報利用の範囲に救急診療時の 97 情報提供は含まれていると考えてもよいと思われ、患者がこうした利用 に備えてハブセンターに診療情報を預託することに同意しているのであ れば、救急診療時に、搬送先の医療機関はその情報を入手できるように することが現実的であると考えられた。また、患者は事後に、ハブセン ターから救急医療情報の利用通知を受け、利用履歴を知ることができる ため、紙や電話での問い合わせ状況について患者が知らされないままと なることが多い現状よりも良いであろう。 今回の実証実験により、救急診療情報利用の通知は、患者に対してだ けでなく発行元医療機関に対しても行われたほうが、診療記録に残せる といったメリットがあるため、望ましいと考えられた。 8.1.7. セキュリティー確保に関わる総合的な課題 8.1.7.1. 地域医療情報連携ハブセンター運用機関の責任分界 医療情報システムの安全管理に関するガイドライン第 4.1 版では、4.2 節、4.3 節に 2 つの医療機関間の送受信に介在する情報処理業者との責任 分界について次のような記述がある。 医療情報が電子化され、ネットワーク等を通じて送受信して情報を提供する場合、第三者 提供の際にも、医療機関等から受信側へ直接情報が提供されるわけではなく、情報処理関 連事業者が介在することがある。この場合、いつの時点で、第三者提供が成立するのか、 すなわち情報処理関連事業者との責任分界点の明確化と言うべき概念が新たに発生する。 いったん適切・適法に提供された医療情報については送信側の医療機関等に責任はないこ とは先に述べたとおりであるが、第三者提供の主体は送信側の医療機関等であることから みて、患者に対する関係では、少なくとも情報が受信側に到達するまでは、原則として送 信側の医療機関等に責任があると考えることができる。その上で、情報処理関連事業者及 び送信側との間で、前項にいうところの善後策を講ずる責任をいかに分担するかは、予め 協議し明確にしておくことが望ましい。選任監督義務を果たしており、特に明記されてい ない場合で情報処理関連事業者の過失によるものである場合は、情報処理関連事業者がす べての責任を負うのが原則である。 また事例として、医療機関に対する考え方として、次の記載がある。 98 「情報処理関連事業者の提供するネットワーク」を通じて医療情報の提供元医療機関等と 提供先医療機関等で患者情報を交換する場合の責任分界点 ここでいう「情報処理関連事業者の提供するネットワーク」とは、情報処理関連事業者の 責任でネットワーク経路上のセキュリティを担保する場合を言う。提供元医療機関等と提 供先医療機関等はネットワーク経路における責任分界点を定め、不通時や事故発生時の対 処も含めて契約等で合意しておく。その上で、自らの責任範囲において、情報処理関連事 業者と管理責任の分担について責任分界点を定め、委託する管理責任の範囲及びサービス に何らかの障害が起こった際の対処をどの事業者が主体となって行うかを明らかにしてお く。 ただし、委託の場合は、通常運用における責任、事後責任は、原則として提供元医療機関 等にあり、第三者提供において適切に情報が提供された場合は、原則として提供先医療機 関等にあり、情報処理関連事業者に瑕疵のない場合は、情報処理関連事業者に生じるのは 管理責任の一部のみであることに留意する必要がある。 さらに、情報処理関連事業者に対する考え方として、以下の記載があ る。 ①医療情報が発信元／送信先で適切に暗号化／復号される場合の責任分界点 患者情報を送信しようとする医療機関等（発信元）の情報システムにおいて、送信前に患 者情報が暗号化され、情報を受け取った医療機関等(送信先)の情報システムにおいて患者 情報が復号される場合、情報処理関連事業者は盗聴の脅威に対する個人情報保護上の責務 とは無関係であり、責任は限定的になる。この場合、情報処理関連事業者に存在するのは 管理責任であり、ネットワーク上の情報の改ざんや侵入、妨害の脅威に対する管理責任の 範囲やネットワークの可用性等の品質に関して契約で明らかにしておく。 ② 医療情報が情報処理関連事業者の管理範囲の開始点で適切に暗号化される場合の責任 分界点 情報処理関連事業者の中には、例えば暗号化された安全なネットワーク回線の提供を主た るサービスとしている事業者も存在する。そのようなネットワーク回線を使う場合、事業 者が提供するネットワーク回線上における外部からの情報の盗聴や改ざん、侵入等やサー ビスの可用性等の品質については事業者に管理責任が発生する。従って、それらの責任に ついては契約で明らかにしておく。 ただし、事業者が提供するネットワーク回線に到達するまでの管理責任やネットワーク回 線を流れる情報に対する管理責任は医療機関等に存在するため、 「Ⅰ医療機関等における考 え方 ①医療情報の提供元医療機関等と提供先医療機関等の責任分界点」に則った考え方の 整理が必要である。 99 今回、実証実験を行ったケースでは、地域医療情報連携ハブは送受信 医療機関の間に介在する中継センターであり、上記のガイドラインで言 うところの「情報処理関連業者」が運営する中継センターの位置づけと なる。また、VPN を確立するソフトウエアの提供、暗号化のための鍵ペ アの配付を含めて、ハブセンターが行っていることから、「② 医療情報 が情報処理関連事業者の管理範囲の開始点で適切に暗号化される場合の 責任分界点」の範疇に入ると考えられ、実際にサービスとして運用する 場合には、複雑な責任分界を明記する契約書の作成が必要となる。 8.1.7.2. ハブセンターを介在する医療機関同士の間の通信 今回の実証実験では、地域医療情報連携ハブと医療機関との間には、 IP-Sec による VPN が確立され、その経路上に SSL-VPN が形成され、 S/MIME により両端暗号化されたファイルが送受信される構成となって いる。この構成は、前述の安全管理のガイドラインでは、6.11 節の「図 B-2-③-b 中間で複数の閉域ネットワークが相互接続して接続されている 場合」に相当すると考えられるとともに、指摘されているように情報そ のものを暗号化することにより同ガイドラインに準拠していると考えら れる。 VPN 構築をした上で、暗号化ファイルを送受信する必要性については、 過剰という考え方もあるが、今回のケースでは地域医療情報連携ハブは 医療機関以外が運営することを想定するため、情報の暗号化は必須であ ると考えられた。 8.2. 公開鍵ディレクトリサービスに関するルールと必要条件 今回の実証実験で、公開鍵ディレクトリサービスは非常に重要な位置 100 づけを占めている。課題の章で述べたように、現状の診療情報転送にお いて大きな問題は、診療情報を安全に送信できる相手先の電子アドレス が不明であることである。 今回の公開鍵ディレクトリサービスは、単に相手の公開鍵を入手でき るサービスであるだけでなく、そこに登録されている医療機関を選択す るだけで、自動的に公開鍵が入手でき、かつ自動的に送信すべき情報を 相手の公開鍵により暗号化できる契機となる点で重要なサービスである。 公開鍵には発行機関により設定された有効期間があるが、今回の実証 実験では毎回送信時にその時点での有効な公開鍵をディレクトリサービ スから入手できるため、送信側が保存していた公開鍵の有効期限に左右 されることなく送信できる点も意義が大きい。 一方、医療機関が廃止またはサービス参画を廃止した場合に、公開鍵 ディレクトリサービスから登録を削除し、その事由を登録することは今 回できていない。公開鍵ディレクトリサービスにそのような機能をもた せるか、または現役医療機関の全国照会データベースが整備されるよう になれば、1 日 1 回バッチ処理で問い合わせるか、またはリアルタイムで 照会することにより、医療機関の廃止情報を確認することができるよう になるだろう。 以上のことから、医療機関、調剤薬局など医療情報連携を必要とする 機関のディレクトリ情報は、リアルタイム（1 日程度以内のタイムラグ） で登録管理され、公開鍵を発行し登録することも義務づけ、公開鍵ディ レクトリサービスによりリアルタイムで紹介できるようになることが必 要である。 8.3. 患者による情報コントロールのあり方 本実証実験においては、患者向け Web アプリケーションで使用する認 101 証情報は事前に発番しておき、各医療機関に事前配布する運用を想定し、 一定程度の数の患者分を事前に各医療機関に事前配布する運用とした。 患者の通院する医療機関では、患者の希望にしたがって、認証情報を手 渡すとともに、本登録機能を用いて、当該患者の通院する機関情報・患 者番号と患者向けアプリケーションで使用する認証 ID を紐づける。この 一連の機能は、今回の実証実験では実際の患者で運用実験は行わず仮想 的な患者を想定して運用実験を行った。患者が本アプリケーションを利 用するための URL や認証情報(ID、パスワード)は、医療機関での同意書 登録と引き換えに配布される運用を想定する。指定された URL にアクセ スし、配布された ID、パスワードを入力することにより、アプリケーシ ョン機能が利用可能となる。医療機関等の間で送受信された患者自身の 診療データおよび救急診療向け基礎情報の状態を閲覧することができる ようにし、自己情報について送信日時、送信元機関、送信先機関、情報 種別と未読/既読の状態を把握できる。さらに削除したいデータを選択し、 削除依頼ボタンを押下することにより、当該データの登録元機関に対し て削除依頼を通知することができる。登録元の医療機関ではこの情報を 削除する運用を想定している。診療情報連携向けアプリケーションで、 救急診療向けの基礎情報データが受信・参照された場合には、登録され ているメールアドレスに対して、参照された旨の通知が行われ、患者は 自己情報が利用されたことをメールで知ることができる。 このような、患者が診療情報の配送状況を把握し、必要なら削除する ことができる機能は、今回のような診療情報連携では必須であると考え られた。ただし、患者に機能を十分に説明し、希望する患者にログイン アカウントを交付する業務をどこが責任を持って行うべきかについては ルールの整備が必要で、かならずしも診療情報送信元の医療機関である 必要はないと考えられる。京都大学と京都府医師会などに実施されてい る「まいこネット」では、患者の同意を医療機関がとるのではなく、事 前に患者が、NPO 法人が発行するアカウントを取得し、そのアカウント 102 を持っている患者について、診療情報連携を行う仕組みにしており、個々 の医療機関での説明と同意の手間と時間を簡略化するためであると考え られる。 9. 提言に向けて 9.1. 地域医療情報連携ハブセンター実現に向けた制度整備 9.1.1. 診療情報電子的配送サービス 課題の節で述べたように、医療機関、調剤薬局、民間の検査センター などは今や日常的に患者個人識別情報を含む診療情報を、任意の機関対 任意の機関における 1 対 1 間でやりとりする必要性が増大しているにも かかわらず、それを安定的かつ安全に信頼できる方法でサービス提供し ている組織が存在しない。 信書を確実に配送するサービスである郵便事業は、普通郵便の他に、 書留、特定記録、内容証明、配達証明、配達日指定、など種々のオプシ ョンサービスを提供している。ところが、診療情報を電子的に配送する こうした信頼できるサービスは存在しない。 今や、その必要性は急速に増大しており、こうした電子信書配送サー ビスとも言える配送サービスが提供されるべき時代に来ている。診療情 報配送に特化したサービスの姿をイメージして今回の地域医療情報連携 ハブの実証実験は行われた。これにより、このようなサービスの提供に 必要なルールの整備や制度設計のイメージが得られた。 この実現のためには、信頼できる診療情報電子的配送サービスを実現 し運用できる主体的事業者として、どのような条件が必要であるかにつ いて、制度設計が必要である。具体的には、信書を配達する郵便事業の 例や、電話等のサービスが電気通信事業法に基づき認可された事業者に 103 より運営されている例を考えると、準公的な性格を持つ組織もしくは、 国が一定の法令に基づき認定する組織が運営することが適切である可能 性があり、その場合には、電子診療情報の配送事業に関する法令の整備 が必要と考えられる。 地域医療情報連携ハブセンターは、国内のネットワーク帯域事情や大 規模医療機関や診療所の地域的な分布特性を考慮し、2 つのセンターで冗 長化してデータを中継できるようにバックアップ体制をとることを想定 して、国内に数カ所設置されると、安定したサービスが提供できるよう になると考えられる。こうした安定したサービス提供が事業者により実 現できるように制度設計が望まれる。 9.1.2. 全機関の公開鍵証明発行・登録・検索サービス 地域医療情報連携ハブセンターによる電子診療情報の配送事業は、全 国のすべての医療機関（診療所、病院、歯科診療所）とすべての調剤薬 局が、利用するかどうかは別として登録されていることを前提とすべき である。 ある医療機関が他の医療機関あてに診療情報を提供して患者を紹介す ることは、任意の 1 対 1 機関間である日突然に起こり得るからである。 現在、すべての医療機関、調剤薬局は、開設・廃止・異動にあたって 都道府県の保健所および、保険医療を行う場合には社会保険事務所にも 申請書もしくは届け出書を出している。従って現状のこの手続きを利用 として、委託された第三者機関が全機関を対象に電子アドレスと公開鍵 証明書を発行して医療機関に交付するものとし、医療機関はこれを地域 医療情報連携ハブに登録するという制度の導入が考えられる。あるいは、 第三者機関が直接、地域医療情報連携ハブに自動登録するという制度の 導入も考えられる。 技術的な実現手法としては、上述したようにすべての医療機関が、他 104 の医療機関から電子診療情報提供を受けたり、調剤薬局から調剤実施情 報を電子的に受信したりする可能性を持つためには、すでにレセプトコ ンピュータの普及率が医療機関で 80％に達しており、調剤薬局ではほぼ 100％に達している現状を考えると、レセプトコンピュータか電子カルテ システムにこうした電子診療情報の送受信通知機能を持たせるなどを検 討することにより、たとえ電子カルテ化されていない診療所等でも診療 情報の送受信、特に受信だけは可能とすると良いと考えられる。 次に重要な点は、公開鍵証明書が現在、個人に対して発行されるもの であり、組織に対して発行されるルールになっていないことである。そ のため、電子診療情報を送付する際に送付先医療機関としての公開鍵に より暗号化することが一般的にはできない。しかし実際の場面では、送 信先医療機関の病院長や特定の医師個人にあてて診療情報提供書を作成 するのではなく、医療機関もしくは医療機関の診療科宛に作成し送付す ることがほとんどである。今回は、特別に組織型の公開鍵証明書を発行 して対応したが、このままでは正規の信頼できる公開鍵証明として普及 させることはできない。 9.2. ガイドラインの整備について 9.2.1. 診療情報の電子的到達確認に関するガイドライン 現在、各地で試みられているインターネットなどを活用した診療情報 連携において、診療情報の到達確認に関するルールが不在であることが 問題である。 診療情報中継を確実に行うためには、情報送信元医療機関に対して、 配達できたかどうか、送信先が受信を確実に行ったかどうかを通知する 機能が必要である。これは患者が自分で紹介状を届ける現状のスタイル では患者に責任があるので問題とならないが、電子的に送信した場合に 105 は、送受信が確実に行われたかについて双方の医療機関同士で確認でき る機能が必要になる。しかし、このルールについて整備されていない。 受信者が明示的に送信元に受信通知を行うのか、それとも配送サービ スが責任を持つのか、また不達通知を受信した送信元医療機関は一定時 間内にセンターに対して不達状態を承認して配送待ちを継続するか、ま たは直接、送信先医療機関に別の連絡手段により連絡するかについて意 思登録ができる運用ルールの整備が必要である。また、送信先医療機関 に対して、受信通知を通知後、一定期間内での受信がない場合には、督 促通知を出す機能も、上記と合わせて必要になる。 こうした送受信履歴の管理と、配送ができていない場合の取り扱いに ついては、ガイドラインとして厚生労働省や医療界が通信サービス事業 者とともに整備していくことが必要である。 9.2.2. 診療情報電子的配送サービスと医療機関との責任分界 診療情報の電子的配送サービスを実現する地域医療情報連携ハブセン ターと医療機関の責任分界点について、こうしたサービス事業者と医療 機関が合意できる契約書の雛型が存在しておらず、仮に事業者が責任分 界を明確にした契約書を提示したとしても、それが適切なものであるか を医療機関が判断出来ないケースが多く、診療情報の電子的連携を行う 際のハードルの高さになっている。したがって、ここで提案する地域医 療情報連携ハブセンターが医療機関に提示する契約書の雛型は、公的な 機関が作成しておく必要があると考える。 契約書の雛型作成にあたっての考え方は、次の通りである。 事業者自身が情報送信元および情報送信先の双方の医療機関での暗号 化・復号化設備と送受信設備をソフトウエアを含めて貸与等により提供 する場合には、その信頼性確保を含めた管理責任はサービス事業者にあ る。 106 一方、上記設備で暗号化処理直前までの情報管理責任および復号化処 理以降の情報管理責任は、医療機関側にある。 次に、事業者が情報送受信のための手順と暗号化・復号化手順および それらが満たすべき基準を医療機関に提示し、医療機関がそれに従った 設備（ソフトウエアを含む）を導入し運用する場合には、事業者のハブ にデータを着信させる時点まで、およびハブからデータを送信させる時 点以降の管理責任は、それぞれ送信元医療機関、送信先医療機関にある。 但し、事業者が医療機関に提示する手順および基準についての品質管理 責任は事業者に帰する。 また、事業者がハブでデータを受信してから、蓄積、送信するまでの 間の管理責任は事業者にある。 なお、事業者の運営するハブと送信元医療機関もしくは送信先医療機 関との間のネットワーク通信路における情報管理責任は、それぞれにお いて通信路を契約した主体（事業者または医療機関）とネットワーク通 信路を提供する事業者との契約に委ねられると考えられる。 9.2.3. 個人情報保護ガイドラインにおける救急時診療情報の取扱い 今回の実験において、あらかじめ診療情報提供先の医療機関を診察時 に特定できる場合には、患者もその診療情報提供先に情報が提供される ことを同意しているので、送受信に介在するハブセンターおよびそれを 運営する組織が一定のルールに従って安全に情報を配送するサービスを 提供しているのであれば、特に別途の同意が必要であるとは考えにくい。 一方で、救急搬送時などに備えて主要な診療情報をあらかじめ預託して おく場合には、預託後に情報を必要とする医療機関に利用されることは、 医療機関同士で必要と考えられる範囲では問題ないと考えられるが、預 託時には患者の同意が必要になると考えられた。しかし、そのことを含 めて診療契約時にオプトアウト方式で掲示などにより事前同意を取れば よいのではないかという考え方もある。 107 医療者の立場で言えば、一定の法令基準を遵守しているハブセンター に対しては、直近の処方情報、直近の治療病名、血液型、重要なアレル ギー情報、手術治療歴、直近の重要な検査結果の異常値、程度の情報に ついては、医療機関の責任で事前登録しておくことがむしろ患者の利益 を代表するのではないかと考えている。 このような利用形態を想定したガイドラインの整備が必要であり、現 行の「医療・介護関係事業者における個人情報の適切な取扱いのための ガイドライン」の改訂などでの対応が望まれる。 具体的には、同ガイドラインのⅢ 医療・介護関係事業者の義務等、の ５．個人データの第三者提供、において、 （３）本人の同意が得られてい ると考えられる場合についての記載中に「第三者への情報の提供のうち、 患者の傷病の回復等を含めた患者への医療の提供に必要であり、かつ、 個人情報の利用目的として院内掲示等により明示されている場合は、原 則として黙示による同意が得られているものと考えられる」との表現が あるため、この例示として「院内掲示に、救急診療のための情報連携ハ ブセンター等に救急診療に必要となる診療情報を事前に預けておくこと を明示し、そのハブセンター名や所在地等の情報をあわせて掲示する場 合には、個別に拒否の申し出がない限り、当該センター等に診療情報を 事前に預け救急診療時に他の医療機関が参照できるようにすることは前 記記載の範囲である」ことを追加する、などの対応が考えられる。 9.3. 医療情報システム業界における新たな対応の必要性 9.3.1. 組織型の公開鍵証明書の必要性 公開鍵証明書は現在、個人に対して発行されるものであり、組織に対 して発行されるルールになっていない。そのため、電子診療情報を送付 する際に送付先医療機関としての公開鍵により暗号化することが一般的 にはできない。しかし実際の場面では、送信先医療機関の病院長や特定 108 の医師個人にあてて診療情報提供書を作成するのではなく、医療機関も しくは医療機関の診療科宛に作成し送付することがほとんどである。つ まりそういう意味では、医療機関という組織間での文書であって、個人 間での文書ではない。今後、組織自体に対して公開鍵証明を発行できる ルールの整備が業界でなされる必要であると考えられる。 また、公開鍵ディレクトリーサービスは、配送事業と一体となって運 用されるのが適切であると考えられるが、前述したようにすべての医療 機関の開設・廃止・異動情報が迅速に反映される制度のもとで、運用さ れる必要がある。 9.4. 国際展開の可能性 診療情報の信頼できる配送を目的とした「診療情報電子的配送サービ ス」を技術的なシステムだけでなく、その運用ルールやガイドラインと 一体となったビジネスシステムと見ると、次の２つの点で国際的な展開 が可能である。 第一は、日本と同様に国内の医療機関同士で電子的に診療情報を確実 に連携させて診療を効率的に行いたいというニーズは、多くの国々で共 通のものであり、どの国でもセンターサーバにデータを共有したりデー タ所在情報だけを共有したり患者に電子診療情報を管理させたり、様々 な試行錯誤を行っているが、いまだに決定的なソリューションを見いだ せていない点である。しかし歴史の長い郵便サービスでわかるように、 必要な情報だけを必要な相手先に確実に届けるという最もシンプルな要 求に応えるサービスを実現することが、実はあらゆる国で実現可能な診 療情報連携の基盤であると考えられ、 「診療情報電子的配送サービス」は その点で発展途上国を含むどの国でも国内サービスとして導入できる可 能性がある。 第二は、 「診療情報電子的配送サービス」は、国内の医療機関同士の診 109 療情報連携だけでなく、国際郵便と同様に国境を越えた医療機関同士で も実現が容易である点である。例えば、日本人が国内での診療情報を救 急時診療情報として事前預託しておき、国外滞在中に海外の医療機関を 受診する場合にも威力を発揮するし、日常的に異なる医療制度の国の間 を行き来する EU 諸国間での診療情報連携にも活用できる。 以上の視点から、 「診療情報電子的配送サービス」による医療機関同士 の診療情報連携、救急時診療情報預託は、国内で制度整備とルール整備 を行うことにより早期に実現し、国際展開を目指すことが望まれる。 10. まとめ 医療機関、調剤薬局などの医療関連機関の相互間で、安全、確実かつ 信頼のおける形態で簡単に診療情報を配送できる地域医療情報ハブを構 築し、その運用実験を行った。全医療機関、全調剤薬局を対象として制 度的に機関の電子アドレス情報と公開鍵証明情報が登録され、電子情報 を送信したい医療機関や調剤薬局が公開鍵ディレクトリサービスにより その情報を検索・取得して、電子診療情報を確実かつ安全に相手医療機 関に送信できることが必要であると考えられた。また、医療機関等の開 設・廃止・異動に関する情報を制度的に一元収集し、電子情報配送サー ビス提供者としての条件を明確にし、医療機関と電子情報配送サービス 提供者との責任分界を明示した契約書の在り方、組織単位の公開鍵証明 発行のルール、救急診療時に備えた重要な診療情報の事前預託ルールの 整備、特にその際の患者の同意の取り方と範囲についてガイドラインの 整備などを検討していくことが必要であると考えられた。 110 11. 参考資料 11.1. 参加医療機関 東京大学医学部附属病院以外の実証実験への参加医療機関は次のとお り。 診療所名 医療法人社団博由会 四谷内科 医療法人社団 聖桐会 御茶の水聖橋クリニック 医療法人社団健康会 高橋医院桜木 医療法人社団 ナグモ会 ナグモクリニック 上六ッ川クリニック 11.2. 医療機関番号 住所 1310437921 新宿区左門町 20 番地 四谷メディカルビル 2F 1310527374 文京区湯島 1 丁目 9‐15 茶州ビル 2Ｆ 1310629717 台東区上野桜木 1‐13‐6 旭ビル 1F 1310930545 1410504639 品 川 区 大 崎 1 ‐ 11 ‐ 2 ゲ ー ト シ テ ィ 大 崎 イーストタワー1F 横浜市南区六ツ川 1-873-3 システムマニュアル （次ページ以降） 111 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥࠉ⏬㠃㑄⛣ᅗ ⏝⪅ᶒ㝈㸸་⒪ᶵ㛵 9HUVLRQ ㉳ື +70/ ࢱࣈษ࡛᭰ࠊ ⏝⪅ࡢ௵ពࡢ⏬㠃ࢆ㑅ᢥྍ⬟ ㉳ື࣎ࢱࣥᢲୗ ㄆド ➃ᮎㄆド$1'ド᫂᭩ㄆドド᫂᭩ㄆドࡣึᅇࡢࡳ ࢹ࣮ࢱ ㏦ಙ ሗ✀ู㑅ᢥ $1' ධຊ࣎ࢱࣥᢲ ㏦ಙࢹ࣮ࢱᒚṔ ⏬ീ᳨ᰝ⤖ᯝࣇࣝ㑅ᢥ ᩆᛴྥࡅ ᇶ♏ሗ Ⓩ㘓 ཷಙࢹ࣮ࢱ୍ぴ ᝈ⪅ㄆド ሗ Ⓩ㘓 ྠព᭩ Ⓩ㘓 ཷಙࢹ࣮ࢱ㑅ᢥ $1' ཷಙ࣎ࢱࣥᢲୗ ཷಙࣇ୍ࣝぴ ཷಙ ࣭࣭࣭ ཷಙࣇࣝྡ ࢡࣜࢵࢡ デ⒪ሗ ᥦ౪᭩ ධຊ ᳨య᳨ᰝ⤖ᯝ ධຊ ͤ㛤Ⓨ୰ ಖᏑ 25࢟ࣕࣥࢭࣝ ࢹ࣮ࢱ⾲♧ ࣉࣜࢣ࣮ࢩࣙࣥ ࣭࣭࣭ ͤཷಙࣇ୍ࣝぴཷಙᩆᛴ⏬㠃ࡣฟඖ⏬㠃࡛ࡢཷಙࢹ࣮ࢱ௳ᩘศࠊ⾲♧ࡉࢀࡿࠋ ࠉࢹ࣮ࢱ⾲♧ࣉࣜࢣ࣮ࢩࣙࣥࡣࣇࣝᙧᘧ⣣ࡅタᐃࡉࢀࡓࣉࣜࢣ࣮ࢩࣙࣥࠋ 㻝㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥࠉ⏬㠃㑄⛣ᅗ ⏝⪅ᶒ㝈㸸ᩆᛴᶵ㛵 9HUVLRQ ㉳ື +70/ ࢱࣈษ࡛᭰ࠊ ⏝⪅ࡢ௵ពࡢ⏬㠃ࢆ㑅ᢥྍ⬟ ㉳ື࣎ࢱࣥᢲୗ ㄆド ➃ᮎㄆド$1'ド᫂᭩ㄆドド᫂᭩ㄆドࡣึᅇࡢࡳ ࢹ࣮ࢱ ㏦ಙ ሗ✀ู㑅ᢥ $1' ධຊ࣎ࢱࣥᢲ ㏦ಙࢹ࣮ࢱᒚṔ ⏬ീ᳨ᰝ⤖ᯝࣇࣝ㑅ᢥ ᩆᛴྥࡅ ᇶ♏ሗ Ⓩ㘓 ཷಙࢹ࣮ࢱ୍ぴ ཷಙࢹ࣮ࢱ㑅ᢥ $1' ཷಙ࣎ࢱࣥᢲୗ ཷಙࣇ୍ࣝぴ ཷಙ ࣭࣭࣭ ཷಙࣇࣝྡ ࢡࣜࢵࢡ デ⒪ሗ ᥦ౪᭩ ධຊ ᳨య᳨ᰝ⤖ᯝ ධຊ ͤ㛤Ⓨ୰ ಖᏑ 25࢟ࣕࣥࢭࣝ ࢹ࣮ࢱ⾲♧ ࣉࣜࢣ࣮ࢩࣙࣥ ࣭࣭࣭ ᩆᛴྥࡅ ᇶ♏ሗ ᳨⣴ ᝈ⪅ㄆド ሗ Ⓩ㘓 ᩆᛴሗ㑅ᢥ $1' ཷಙ࣎ࢱࣥᢲୗ ཷಙࣇ୍ࣝぴ ᩆᛴ ࣭࣭࣭ ཷಙࣇࣝྡ ࢡࣜࢵࢡ ࢹ࣮ࢱ⾲♧ ࣉࣜࢣ࣮ࢩࣙࣥ ࣭࣭࣭ ͤཷಙࣇ୍ࣝぴཷಙᩆᛴ⏬㠃ࡣฟඖ⏬㠃࡛ࡢཷಙࢹ࣮ࢱ௳ᩘศࠊ⾲♧ࡉࢀࡿࠋ ࠉࢹ࣮ࢱ⾲♧ࣉࣜࢣ࣮ࢩࣙࣥࡣࣇࣝᙧᘧ⣣ࡅタᐃࡉࢀࡓࣉࣜࢣ࣮ࢩࣙࣥࠋ 㻞㻌㻛㻌㻢㻜㻌䝨䞊䝆 112 ྠព᭩ Ⓩ㘓 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉ⏝⪅ྥࡅ㹕㹣㹠ࣉࣜࢣ࣮ࢩࣙࣥࠉ⏬㠃㑄⛣ᅗ ⏝⪅ᶒ㝈㸸⏝⪅ᝈ⪅ 9HUVLRQ ࣮ࣘࢨ࣮ㄆド ㄆド㹇㹂$1'ࣃࢫ࣮࣡ࢻධຊ Ⓩ㘓῭ࡳ ⏝⪅ ࣓࣮ࣝࢻࣞࢫ ᮍⓏ㘓 ࢟ࣕࣥࢭࣝ ࣓࣮ࣝࢻࣞࢫ Ⓩ㘓 ⏝⪅ྥࡅ ࢹ࣮ࢱ୍ぴ ࣓࣮ࣝࢻࣞࢫࡢኚ᭦ ࢟ࣕࣥࢭࣝ ࣓࣮ࣝࢻࣞࢫ Ⓩ㘓 ࢩࢫࢸ࣒ྠព⏝ࡢ᧔ᅇ ࢩࢫࢸ࣒⏝ ྠព᭩᧔ᅇ ࢟ࣕࣥࢭࣝ 㻟㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥ᧯స ࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥࡢ㉳ື㹼ㄆド ㉳ື⏬㠃ࡢ⾲♧ࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥࡢ㉳ື ࣥࢱ࣮ࢿࢵࢺ࢚ࢡࢫࣉ࣮࣮࡛ࣟࣛୗグࡢ㹓㹐㹊ࡢ⏬㠃ࢆ⾲♧ࡋࡲࡍࠋ ㉳ື⏬㠃㹓㹐㹊㸸 KWWSVFHQWHUPVF]KXWRN\RDFMSPHGLFLQIFOLHQWLQGH[KWPO ձ ㉳ື࣎ࢱࣥࢆࢡࣜࢵࢡࡋࡲࡍࠋ ࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥࡀࢧ࣮ࣂ࣮ࡽࢲ࣮࢘ࣥࣟࢻࡉࢀࠊ ⮬ື࡛㉳ືࡋࡲࡍࠋ ͤ᧯సㄝ᫂᭩ࢆࢡࣜࢵࢡࡍࡿࠊᮏ᭩ࡀ㛤ࡁࡲࡍࠋ ͤ ձ ͤ⏬ീࡢ85/ࡣ㛤Ⓨ⏝ࡢⅭࠊᐇ㝿ࡢ85/ࡣ␗࡞ࡾࡲࡍࠋ 㻠㻌㻛㻌㻢㻜㻌䝨䞊䝆 113 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ͤ ࣉࣜࢣ࣮ࢩࣙࣥ㉳ື⏬㠃ࡢࢭ࢟ࣗࣜࢸ㆙࿌ ㉳ື⏬㠃ࡢド᫂᭩ࢆ᳨ド࡛ࡁ࡞࠸ሙྜࠊୗグࡢ࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ձ ࣉࣜࢣ࣮ࢩࣙࣥࢆ㉳ືࡍࡿሙྜࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ㏻ᖖࡣࡇࡕࡽ ࣉࣜࢣ ࢩࣙࣥࡢ㉳ືࡋ࡞࠸ሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ࣉࣜࢣ࣮ࢩࣙࣥࡢ㉳ືࡋ࡞࠸ሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ͤ ࣉࣜࢣ࣮ࢩࣙࣥ㉳ືࡢド᫂᭩☜ㄆ ࣉࣜࢣ࣮ࢩࣙࣥࡢド᫂᭩ࢆ᳨ド࡛ࡁ࡞࠸ሙྜࠊୗグࡢ࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ࣉࣜࢣ࣮ࢩࣙࣥࢆ㉳ືࡍࡿሙྜࠊᐇ⾜࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ㏻ᖖࡣࡇࡕࡽ ࣉࣜࢣ࣮ࢩࣙࣥࡢ㉳ືࡋ࡞࠸ሙྜࠊྲྀᾘࡋ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ͤ ḟᅇ௨㝆ࠊࡇࡢ㆙࿌࣓ࢵࢭ࣮ࢪࢆ⾲♧ࡋ࡞࠸ࡼ࠺ࡍࡿࡣ ࡇࡢࢳ࢙ࢵࢡ࣎ࢵࢡࢫࢆࢳ࢙ࢵࢡࡋ࡚ୗࡉ࠸ࠋ ͤ ࡇࡢ㆙࿌࣓ࢵࢭ࣮ࢪࡣࣉࣜࢣ࣮ࢩࣙࣥᮏయࠊ ࣉࣜࢣ࣮ࢩࣙࣥࡀ⏝ࡍࡿࣇࣝࡢᩘࡔࡅ⾲♧ࡉࢀࡲࡍࠋ ձ ͤ 㻡㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ࢡࣛࣥࢺㄆド ͤึᅇ㉳ື ͤᅇ┠௨㝆ࡢ㉳ື ձ ձ ղ ղ ճ մ մ ձ 㹎㹁ࣟࢢ࢜ࣥࡍࡿ㝿ධຊࡍࡿࣟࢢ࢜ࣥྡࢆධຊࡋ࡚ୗࡉ࠸ࠋ ղ 㹎㹁ࣟࢢ࢜ࣥࡍࡿ㝿ධຊࡍࡿࣟࢢ࢜ࣥࣃࢫ࣮࣡ࢻࢆධຊࡋ࡚ୗࡉ࠸ࠋ ճ ⟶⌮⪅ࡼࡾ㏦ࡉࢀࡓㄆドド᫂᭩ࡢࣃࢫ࣮࣡ࢻࢆධຊࡋ࡚ୗࡉ࠸ࠋ ͤ ㄆドド᫂᭩ࡢࣃࢫ࣮࣡ࢻࡣึᅇࡢࡳධຊࡋࡲࡍࠋ ṇࡋ࠸ࣃࢫ࣮࣡ࢻࡀධຊࡉࢀࡿࣉࣜࢣ࣮ࢩࣙࣥࡀࡑࡢࣃࢫ࣮࣡ࢻࢆグ㘓ࡋࠊ ḟᅇ௨㝆ࡣࣉࣜࢣ࣮ࢩࣙࣥࡀ⮬ື࡛ࢳ࢙ࢵࢡࢆ⾜࠸ࡲࡍࠋ մ ୖグձ㹼ճࡢධຊ್࡛ㄆドࡍࡿሙྜࠊㄆド࣎ࢱࣥࢆᢲୗࡋࡲࡍࠋ ࣉࣜࢣ࣮ࢩࣙࣥࡢ⏝ࢆṆࡵࡿሙྜࠊ㛢ࡌࡿ࣎ࢱࣥࢆᢲୗࡋࡲࡍࠋ 㻢㻌㻛㻌㻢㻜㻌䝨䞊䝆 114 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥ᧯స⏬㠃⾲♧ ୖグࡢㄆドࢳ࢙ࢵࢡ⤖ᯝࡀṇᖖࡢሙྜࠊࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥࡢ᧯స⏬㠃ࡀ⾲♧ࡉࢀࡲࡍࠋ 㻣㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥ᧯స ࢹ࣮ࢱ㏦ಙ ࢧ࣮ࣂ࣮ࢹ࣮ࢱࣇࣝࢆ㏦ಙࡋࡲࡍࠋ ࢹ࣮ࢱ㏦ಙ⏬㠃ࡢ⾲♧ ձ ձ ⏬㠃ୖ㒊ࡢ㏦ಙࢱࣈࢆࢡࣜࢵࢡࡋࡲࡍࠋ ͤ ⏬㠃ࢆ⾲♧ࡋ࡚࠸ࡿሙྜᚲせ࡞᧯స࡛ࡍࠋ ᪤⾲♧ࡉࢀ࡚࠸ࡿሙྜࡣᚲせ࠶ࡾࡲࡏࢇࠋ 㻤㻌㻛㻌㻢㻜㻌䝨䞊䝆 115 Copyright(C)2010 by The University of Tokyo ㏦ಙࢹ࣮ࢱࡢ㏦ಙሗタᐃ㏦ಙࢹ࣮ࢱධຊ⏬㠃⾲♧ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ղ ճ ձ մ յ ձ ղ ճ մ ն ࢹ࣮ࢱࡢ㏦ಙඛࡢ་⒪ᶵ㛵ࢆ㑅ᢥࡋࡲࡍࠋ ㏦ಙࡍࡿࢹ࣮ࢱࡢᝈ⪅ሗᝈ⪅ྡࢆධຊࡋࡲࡍࠋ ㏦ಙࡍࡿࢹ࣮ࢱࡢᝈ⪅ሗᝈ⪅,'ࢆධຊࡋࡲࡍࠋ ㏦ಙࡍࡿࢹ࣮ࢱࡢᝈ⪅ሗ⏕ᖺ᭶᪥ࢆධຊࡋࡲࡍࠋ ௨㝆ࡢ᧯సࡣࠊデ⒪ሗᥦ౪᭩࡞ࡢ⏬㠃ධຊࢆᚲせࡍࡿ㏦ಙࢹ࣮ࢱࡢሙྜ⾜࠺᧯స࡛ࡍࠋ ᮏ᭩࡛ࡣデ⒪ሗᥦ౪᭩ࢆㄝ᫂ࡋࡲࡍࠋ յ ㏦ಙࢹ࣮ࢱࡢሗ✀ูࢆ㑅ᢥࡋࡲࡍࠋ ն ධຊ࣎ࢱࣥࢆᢲୗࡋࡲࡍࠋ 㻥㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ㏦ಙࢹ࣮ࢱࡢධຊ ୖグնࡢ᧯సࡼࡾධຊ⏬㠃ࡀู࢘ࣥࢻ࡛࢘⾲♧ࡉࢀࡿࡢ࡛ࠊᚲせ࡞ࢹ࣮ࢱࢆධຊࡋࡲࡍࠋ ͤୗ᪉⏬㠃ࢫࢡ࣮ࣟࣝ ձ ձ ձ ධຊࡋࡓෆᐜࢆⓏ㘓ࡍࡿሙྜࠊⓏ㘓࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ デ⒪ሗᥦ౪᭩ࢹ࣮ࢱࡢධຊ᧯సࢆ୰᩿ࡍࡿሙྜࠊ࢟ࣕࣥࢭࣝ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ධຊࡋࡓෆᐜࢆ࡚ࢡࣜࡍࡿሙྜࠊࢡࣜ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ͤ ࢹ࣮ࢱ㏦ಙ⏬㠃࡛㑅ᢥࠊධຊࡋࡓ㏦ಙඛᶵ㛵ࡸᝈ⪅ሗࡣධຊ⏬㠃࡛ࡣኚ᭦࡛ࡁࡲࡏࢇࠋ ኚ᭦ࡍࡿሙྜࡣࠊ࢟ࣕࣥࢭࣝ࣎ࢱࣥࢆᢲୗࡋ࡚ࢹ࣮ࢱ㏦ಙ⏬㠃ᡠࡗ࡚ኚ᭦ࡋ࡚ୗࡉ࠸ࠋ ධຊࢹ࣮ࢱࡢಖᏑ☜ㄆ ୖグձ࡛Ⓩ㘓࣎ࢱࣥࢆᢲୗࡋࡓሙྜࠊධຊࢹ࣮ࢱಖᏑ☜ㄆࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ධຊࢹ࣮ࢱࢆಖᏑࡍࡿሙྜࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ධຊࢹ࣮ࢱࡢಟṇ➼࡛ಖᏑࡋ࡞࠸ሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㻝㻜㻌㻛㻌㻢㻜㻌䝨䞊䝆 116 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ಖᏑ࣓ࢵࢭ࣮ࢪ⾲♧ ୖグձ࡛ࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋṇᖖࢹ࣮ࢱಖᏑࡀࡍࡿࠊಖᏑࡢ࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ゎ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ධຊ⏬㠃࢘ࣥࢻ࢘ࡀࢡ࣮ࣟࢬࡋࠊࢹ࣮ࢱ㏦ಙ⏬㠃ᡠࡾࡲࡍࠋ ձ ධຊࢹ࣮ࢱࡢ㏦ಙࢹ࣮ࢱ୍ぴࣜࢫࢺࡢ㏣ຍ ධຊࡋࡓࢹ࣮ࢱࡀ㏦ಙࣇ୍ࣝぴ㏣ຍࡉࢀࡲࡍࠋ 㻝㻝㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ㏦ಙࢹ࣮ࢱࡢ㑅ᢥ ⏬ീ᳨ᰝ⤖ᯝࣇࣝ',&20ࡸࠊࡑࡢᩥ᭩3')ࣇࣝࢆ㏦ಙࡍࡿሙྜࠊ ࡑࡢࣇࣝࢆ㑅ᢥࡋ㏦ಙࣇ୍ࣝぴࣜࢫࢺ㏣ຍࡋࡲࡍࠋ ͤ ධຊࢹ࣮ࢱࣇࣝ㑅ᢥࢹ࣮ࢱࡣࢭࢵࢺ࡛࡞ࡃ࡚ࡶಶࠎ㏦ಙྍ⬟࡛ࡍࠋ ణࡋࠊࡕࡽࢆ㏦ࡿࡋ࡚ࡶᐄඛᝈ⪅ሗࡣᚲ㡲࡞ࡾࡲࡍࠋ ձ ղ ձ ሗ✀ูࡽ⏬ീ᳨ᰝ⤖ᯝሗࡲࡓࡣࠊࡑࡢᩥ᭩3')ࢆ㑅ᢥࡋ࡚ୗࡉ࠸ࠋ ղ ୖグձࡢ࠸ࡎࢀࡢ㑅ᢥࡼࡾࠊཧ↷࣎ࢱࣥࡀ⏝ྍ⬟࡞ࡾࡲࡍࡢ࡛ᢲୗࡋ࡚ୗࡉ࠸ࠋ 㻝㻞㻌㻛㻌㻢㻜㻌䝨䞊䝆 117 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ㏦ಙࢹ࣮ࢱࣇࣝࡢ㑅ᢥ ࣇࣝ㑅ᢥࢲࣟࢢ࣎ࢵࢡࢫࡀ⾲♧ࡉࢀࡿࡢ࡛ࠊ㏦ಙࢹ࣮ࢱࣇࣝࢆ㑅ᢥࡋ࡚ୗࡉ࠸ࠋ ձ ձ 㑅ᢥࡋࡓࣇࣝࢆ㏦ಙࢹ࣮ࢱࡍࡿሙྜࠊ㛤ࡃ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ㏦ಙࢹ࣮ࢱࣇࣝࡢ㑅ᢥࢆ୰᩿ࡍࡿሙྜࠊྲྀᾘࡋ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ 㻝㻟㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ㏦ಙࣇ୍ࣝぴࡢ㏣ຍ 㑅ᢥࡋࡓ㏦ಙࢹ࣮ࢱࣇࣝࢆ㏦ಙࣇ୍ࣝぴࣜࢫࢺ㏣ຍࡋࡲࡍࠋ ձ ղ ձ ୖグ࡛㑅ᢥࡋࡓ㏦ಙࢹ࣮ࢱࣇࣝࡢྡ⛠ࡀ⾲♧ࡉࢀࡲࡍࠋ ղ ୍ぴ㏣ຍ࣎ࢱࣥࢆᢲୗࡋࡲࡍࠋ ㏦ಙࣇ୍ࣝぴࡢࣜࢫࢺࠊ㑅ᢥࡋࡓ㏦ಙࢹ࣮ࢱࣇࣝࡀ㏣ຍࡉࢀࡲࡍࠋ ͤ ㏦ಙࣇ୍ࣝぴ㏣ຍࡋࡓࡔࡅ࡛ࡣࠊ㏦ಙࢹ࣮ࢱࣇࣝࡣࢧ࣮ࣂ㏦ಙࡉࢀࡲࡏࢇࠋ ࡲࡓࠊ㏦ಙࣇࣝࢆⓏ㘓㑅ᢥࡋ࡚ࡶ㏦ಙࣇ୍ࣝぴࣜࢫࢺ㏣ຍࡋ࡞࠸ ࢧ࣮ࣂ࣮ࡢ㏦ಙᑐ㇟ࡳ࡞ࡉࢀࡲࡏࢇࠋ 㻝㻠㻌㻛㻌㻢㻜㻌䝨䞊䝆 118 Copyright(C)2010 by The University of Tokyo ࢧ࣮ࣂ㏦ಙ ㏦ಙࣇ୍ࣝぴࣜࢫࢺࡢࣇࣝࢆࢧ࣮ࣂ࣮㏦ಙࡋࡲࡍࠋ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ձ ձ ㏦ಙ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋࢧ࣮ࣂ㏦ಙฎ⌮ࢆᐇ⾜ࡋࡲࡍࠋ ࢧ࣮ࣂ࣮㏦ಙฎ⌮ࡢᐇ⾜☜ㄆ ࢧ࣮ࣂ࣮㏦ಙฎ⌮ࡢᐇ⾜☜ㄆࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ࢧ࣮ࣂ࣮㏦ಙฎ⌮ࢆᐇ⾜ࡍࡿሙྜࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ㏦ಙࢹ࣮ࢱࣇࣝࡀࢧ࣮ࣂ࣮㏦ಙࡉࢀࡲࡍࠋ ղ ࢧ࣮ࣂ࣮㏦ಙฎ⌮ࢆ୰᩿ࡍࡿሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㻝㻡㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ྠព᭩Ⓩ㘓ࢳ࢙ࢵࢡ࣓ࢵࢭ࣮ࢪ⾲♧ ㏦ಙࡋࡓࢹ࣮ࢱࡢᝈ⪅ࡢࢩࢫࢸ࣒⏝ྠព᭩ࡀᮍⓏ㘓ࡢሙྜࠊ࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ゎ࣎ࢱࣥᢲୗࡼࡾࠊࢧ࣮ࣂ࣮㏦ಙฎ⌮ࡀ⥆⾜ࡉࢀࡲࡍࠋ ͤ ᮏ࣓ࢵࢭ࣮ࢪࡢ⾲♧ࡼࡾࢧ࣮ࣂ㏦ಙฎ⌮ࡀ୰᩿ࡉࢀࡿࡣ࠶ࡾࡲࡏࢇࠋ ձ ࢧ࣮ࣂ࣮㏦ಙฎ⌮୰ࡢ⏬㠃⾲♧ ࢧ࣮ࣂ࣮ࡢࢹ࣮ࢱ㏦ಙࡀࡍࡿࡲ࡛ࠊࢹ࣮ࢱ㏦ಙ⏬㠃ୖࡢ࡚ࡢ࣎ࢱࣥࡣ⏝ྍ࡞ࡾࡲࡍࠋ 㻝㻢㻌㻛㻌㻢㻜㻌䝨䞊䝆 119 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ࢧ࣮ࣂ࣮㏦ಙฎ⌮ࡢ࣓ࢵࢭ࣮ࢪ⾲♧ ࢧ࣮ࣂ࣮㏦ಙฎ⌮ࡀṇᖖࡋࡓሙྜࠊ࣓ࢵࢭ࣮ࢪࢆ⾲♧ࡋࡲࡍࠋ ձ ゎ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ ࢧ࣮ࣂ࣮㏦ಙฎ⌮ᚋࡢ⏬㠃 ࢹ࣮ࢱ㏦ಙࡢⅭ㑅ᢥධຊࡋࡓሗࡣ࡚ࢡࣜࡉࢀࡲࡍࠋ ͤ ㏦ಙඛࡢᶵ㛵ࢹ࣮ࢱ㏦ಙࢆᐇ⾜ࡋࡓ᪨ࢆ࿌ࡆࡿ࣓࣮ࣝࡀ㏦ಙࡉࢀࡲࡍࠋ 㻝㻣㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 (;㏦ಙࣇ୍ࣝぴࡽࡢ๐㝖 ㏦ಙࣇ୍ࣝぴ㏣ຍࡋࡓ㏦ಙࢹ࣮ࢱࢆ࢟ࣕࣥࢭࣝࡍࡿሙྜࡢ᧯స᪉ἲ࡛ࡍࠋ ձ ղ ճ ձ ㏦ಙࣇ୍ࣝぴࡽ๐㝖ࡍࡿࢹ࣮ࢱࡢ⾜ࢆࢡࣜࢵࢡࡋ࡚ୗࡉ࠸ࠋ ղ ࢡࣜࢵࢡࡋࡓ㏦ಙࢹ࣮ࢱࡢࣇࣝྡࡀ㏦ಙࣇࣝ⾲♧ࡉࢀࡲࡍࠋ ճ ୍ぴࡽ๐㝖࣎ࢱࣥᢲୗ࡛ࠊ㏦ಙࣇ୍ࣝぴࡼࡾ㏦ಙࢹ࣮ࢱࣇࣝࡀ๐㝖ࡉࢀࡲࡍࠋ ͤ デ⒪ሗᥦ౪᭩➼ࡢධຊࢹ࣮ࢱࡣ㏦ಙࣇ୍ࣝぴࣜࢫࢺࡽ๐㝖ࡍࡿࠊ ᗘධຊ⏬㠃ࡽࡢධຊࡀᚲせ࡛ࡍࠋ ͤ ୍ぴࡽ๐㝖㑅ᢥྍ⬟࡞ࢹ࣮ࢱࡣࠊㄗ㑅ᢥ㜵ṆࡢⅭࠊ㸯௳ࡔࡅ࡞ࡗ࡚࠸ࡲࡍࠋ 」ᩘ๐㝖ࡍࡿሙྜࡣࠊୖグձ㹼ճࡢ᧯సࢆ๐㝖௳ᩘศࠊ⧞ࡾ㏉ࡋ࡚ୗࡉ࠸ࠋ 㻝㻤㻌㻛㻌㻢㻜㻌䝨䞊䝆 120 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 (;㏦ಙඛࡢ㏦ಙ㏻▱࣓࣮ࣝ ࢹ࣮ࢱ㏦ಙฎ⌮ࢆᐇ⾜ࡍࡿࡼࡾࠊࢧ࣮ࣂ࣮ࡽ㏦ಙඛࡢᶵ㛵࣓࣮ࣝࡀ㏦ಙࡉࢀࡲࡍࠋ ࣓࣮ࣝࢱࢺࣝ㸸 ࢹ࣮ࢱ㏦ಙࡢ࠾▱ࡽࡏ<<<<00''KKPPVV ͤ <<<<00''KKPPVV ࢹ࣮ࢱ㏦ಙ᪥ ࣓࣮ࣝᮏᩥ ͤ ᶵ㛵ࡢ࣓࣮ࣝࢻࣞࢫࡣࢩࢫࢸ࣒⟶⌮⪅ࡼࡾⓏ㘓ࡉࢀࡲࡍࠋ 㻝㻥㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥ᧯స ㏦ಙࢹ࣮ࢱᒚṔ㏦ಙࢹ࣮ࢱ๐㝖 ࢧ࣮ࣂ࣮㏦ಙࡋࡓࢹ࣮ࢱࣇࣝࡢᒚṔ⾲♧ࠊ㏦ಙ῭ࡳࢹ࣮ࢱࡢ๐㝖ࢆ⾜࠸ࡲࡍࠋ ㏦ಙࢹ࣮ࢱᒚṔ⏬㠃ࡢ⾲♧ ձ ձ ⏬㠃ୖ㒊ࡢ㏦ಙᒚṔࢱࣈࢆࢡࣜࢵࢡࡋࡲࡍࠋ ͤ ⏬㠃ࢆ⾲♧ࡋ࡚࠸ࡿሙྜᚲせ࡞᧯స࡛ࡍࠋ ᪤⾲♧ࡉࢀ࡚࠸ࡿሙྜࡣᚲせ࠶ࡾࡲࡏࢇࠋ 㻞㻜㻌㻛㻌㻢㻜㻌䝨䞊䝆 121 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ㏦ಙࢹ࣮ࢱᒚṔࡢ᳨⣴ ㏦ಙࢹ࣮ࢱᒚṔࢹ࣮ࢱࢆ᳨⣴ࡍࡿ᮲௳タᐃࢆ⾜࠸ࠊ᳨⣴ࢆᐇ⾜ࡋࡲࡍࠋ ձ ղ ձ ㏦ಙ᪥ ᐄඛ ᝈ⪅ྡጣ ᝈ⪅ྡྡ 㸸 㸸 㸸 㸸 ࢹ࣮ࢱ㏦ಙ᪥ࢆᣦᐃࡋ᳨࡚⣴ࡍࡿሙྜࠊᣦᐃ᪥ࢆධຊࡋࡲࡍࠋ ㏦ࡾඛࡢᶵ㛵ྡ⛠ࢆᣦᐃࡋ᳨࡚⣴ࡍࡿሙྜࠊ㑅ᢥࡋࡲࡍࠋ ᝈ⪅ࡢጣ࡛/,.(᳨⣴ࡍࡿሙྜࠊධຊࡋࡲࡍࠋ ᝈ⪅ࡢྡ࡛/,.(᳨⣴ࡍࡿሙྜࠊධຊࡋࡲࡍࠋ ͤ ୖグࡢ㡯┠ࡣ௵ពࡢタᐃ㡿ᇦࡢⅭࠊ࡚ࡢ㡯┠ࢆタᐃࡍࡿᚲせࡣ࠶ࡾࡲࡏࢇࠋ ఱࡶධຊ㑅ᢥࡋ࡞࠸ሙྜࠊ㏦ಙඖࡢᶵ㛵ࡔࡅࢆ᳨⣴᮲௳ࡋࡲࡍࠋ ղ ᳨⣴࣎ࢱࣥࢆᢲୗࡋ࡚ࡃࡔࡉ࠸ࠋ ୖグձࡢ᮲௳࡛㏦ಙࢹ࣮ࢱᒚṔ᳨⣴ฎ⌮ࢆᐇ⾜ࡋࡲࡍࠋ 㻞㻝㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ㏦ಙࢹ࣮ࢱᒚṔࡢ⾲♧ ୖグ࡛ᣦᐃࡋࡓ᮲௳᳨࡛⣴ࡋࡓ⤖ᯝࡀ㏦ಙࢹ࣮ࢱᒚṔࣜࢫࢺ⾲♧ࡉࢀࡲࡍࠋ ͤ ཷಙඛ≧ែ ㏦ಙࡋࡓࢹ࣮ࢱࡢ≧ែࢆពࡋࡲࡍࠋ ᮍㄞ 㸸 ㏦ࡾඛࡢᶵ㛵࡛㏦ಙࢹ࣮ࢱࡢཷಙฎ⌮ࡀ⾜ࢃࢀ࡚࠸ࡲࡏࢇࠋ ᪤ㄞ 㸸 ㏦ࡾඛࡢᶵ㛵࡛㏦ಙࢹ࣮ࢱࡢཷಙฎ⌮ࡀ⾜ࢃࢀࡲࡋࡓࠋ ๐㝖῭ 㸸 ๐㝖ฎ⌮ࡀᐇ⾜ࡉࢀࡓࢹ࣮ࢱ࡛ࡍࠋ ๐㝖౫㢗῭ 㸸 ᝈ⪅ࡀ㹕㹣㹠⏬㠃ࡽ๐㝖౫㢗ࢆᐇ⾜ࡋࡲࡋࡓࠋ 㻞㻞㻌㻛㻌㻢㻜㻌䝨䞊䝆 122 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ㏦ಙࢹ࣮ࢱࡢ๐㝖 ㏦ಙࡋࡓࢹ࣮ࢱࢆ๐㝖ࡋࡲࡍࠋ ͤ ๐㝖ฎ⌮ᑐ㇟ࡢ㏦ಙࢹ࣮ࢱ ཷಙඛ≧ែࡀᮍㄞ᪤ㄞ๐㝖౫㢗῭ࡢሙྜࠊ ๐㝖ฎ⌮ࡀྍ⬟࡛ࡍࠋ ཷಙඛ≧ែࡀ๐㝖῭ࡢሙྜࠊཷಙฎ⌮ࡣ⾜࠼ࡲࡏࢇࠋ ձ ղ ձ ๐㝖ࡍࡿࢹ࣮ࢱࡢࢳ࢙ࢵࢡ࣎ࢵࢡࢫࢆࢡࣜࢵࢡࡋ࡚ࢳ࢙ࢵࢡ㹍㹌≧ែࡋ࡚ୗࡉ࠸ࠋ ղ ๐㝖࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ㏦ಙࢹ࣮ࢱ๐㝖ᐇ⾜☜ㄆࢲࣟࢢࡢ⾲♧ ୖグղࡢ᧯సࡼࡾฎ⌮ࡢᐇ⾜☜ㄆࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ๐㝖ฎ⌮ࢆᐇ⾜ࡍࡿሙྜࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ๐㝖ฎ⌮ࢆ୰᩿ࡍࡿሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㻞㻟㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ๐㝖ฎ⌮࣓ࢵࢭ࣮ࢪࡢ⾲♧ ୖグ࡛ࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋࡓሙྜࠊࢧ࣮ࣂ࡛㏦ಙࢹ࣮ࢱ๐㝖ฎ⌮ࡀᐇ⾜ࡉࡲࡍࠋ ṇᖖ⤊ࡋࡓሙྜࠊฎ⌮ࡢ࣓ࢵࢭ࣮ࢪࢆ⾲♧ࡋࡲࡍࠋ ձ ゎ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ ๐㝖ฎ⌮῭ࡳ㏦ಙࢹ࣮ࢱࡢ⾲♧ ㏦ಙࢹ࣮ࢱᒚṔࣜࢫࢺࡢཷಙඛ≧ែ㡯┠ࡀ๐㝖῭⾲♧ࡉࢀࡲࡍࠋ 㻞㻠㻌㻛㻌㻢㻜㻌䝨䞊䝆 123 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥ᧯స ࢹ࣮ࢱཷಙ ࢧ࣮ࣂ࣮ࡽࢹ࣮ࢱࣇࣝࢆཷಙࡋࡲࡍࠋ ࢹ࣮ࢱཷಙ⏬㠃ࡢ⾲♧ ձ ձ ⏬㠃ୖ㒊ࡢཷಙࢱࣈࢆࢡࣜࢵࢡࡋࡲࡍࠋ ͤ ⏬㠃ࢆ⾲♧ࡋ࡚࠸ࡿሙྜᚲせ࡞᧯స࡛ࡍࠋ ᪤⾲♧ࡉࢀ࡚࠸ࡿሙྜࡣᚲせ࠶ࡾࡲࡏࢇࠋ 㻞㻡㻌㻛㻌㻢㻜㻌䝨䞊䝆 ཷಙࢹ࣮ࢱࡢ㑅ᢥཷಙฎ⌮ᐇ⾜᧯స ཷಙࡍࡿࢹ࣮ࢱࢆ㑅ᢥࡋࠊࢹ࣮ࢱཷಙฎ⌮ࢆᐇ⾜ࡋࡲࡍࠋ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ͤ ཷಙࣇ୍ࣝぴࠉሗ✀ู㡯┠ࡢព ཷಙࢹ࣮ࢱࣇࣝ᱁⣡ࡉࢀ࡚࠸ࡿ ࣇࣝ௳ᩘࢆ⾲ࡋࡲࡍࠋ ᳨ ⏬ デ ձ ͤ 㸸 㸸 㸸 㸸 ᳨య᳨ᰝ⤖ᯝሗࠉࣇࣝ௳ᩘ ⏬ീ᳨ᰝ⤖ᯝሗࠉࣇࣝ௳ᩘ デ⒪ሗᥦ౪᭩ࠉࠉࣇࣝ௳ᩘ ࡑࡢᩥ᭩㹎㹂㹄ࣇࣝ௳ᩘ ཷಙࣇ୍ࣝぴࠉ≧ែ ཷಙࣇࣝࡢ≧ែࢆ⾲ࡋࡲࡍࠋ ᮍㄞ ᪤ㄞ ๐㝖῭ ๐㝖౫㢗῭ ͤ 㸸 㸸 㸸 㸸 ཷಙࢹ࣮ࢱࡣ୍ᗘ」ᩘ௳ࡢ㑅ᢥࡀྍ⬟࡛ࡍࠋ ≧ែ㡯┠ࡀ๐㝖῭ࡲࡓࡣ๐㝖౫㢗῭ࡢࢹ࣮ࢱ ≧ែ㡯┠ࡀ๐㝖῭ࡲࡓࡣ๐㝖౫㢗῭ࡢࢹ ࢱ ࡣཷಙ࡛ࡁࡲࡏࢇࠋ ղ ձ ཷಙࣇ୍ࣝぴࣜࢫࢺࡢཷಙࡍࡿࢹ࣮ࢱࡢ㑅ᢥ㡯┠ࢆࢡࣜࢵࢡࡋࠊࢳ࢙ࢵࢡ21≧ែࡋࡲࡍࠋ ղ ⾲♧࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ࢹ࣮ࢱཷಙฎ⌮ᐇ⾜☜ㄆࢲࣟࢢࡢ⾲♧ ୖグղࡢ᧯సࡼࡾฎ⌮ࡢᐇ⾜☜ㄆࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ࢹ࣮ࢱཷಙฎ⌮ࢆᐇ⾜ࡍࡿሙྜࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ࢹ࣮ࢱཷಙฎ⌮ࢆ୰᩿ࡍࡿሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㻞㻢㻌㻛㻌㻢㻜㻌䝨䞊䝆 124 ࢹ࣮ࢱཷಙฎ⌮ࢆ⾜ࡗ࡚࠸࡞࠸ࢹ࣮ࢱ࡛ࡍࠋ ࢹ࣮ࢱཷಙฎ⌮ࢆ⾜ࡗࡓࢹ࣮ࢱ࡛ࡍࠋ ㏦ಙඖࡢᶵ㛵࡛๐㝖ࡉࢀࡓࢹ࣮ࢱ࡛ࡍࠋ ᝈ⪅ࡀ:HE⏬㠃ࡽ๐㝖౫㢗ࡋࡓࢹ࣮ࢱ࡛ࡍࠋ Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ฎ⌮࣓ࢵࢭ࣮ࢪࡢ⾲♧ ࢹ࣮ࢱཷಙฎ⌮ࡀṇᖖ⤊ࡋࡓሙྜࠊฎ⌮ࢆ࿌ࡆࡿ࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ゎ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ ཷಙࣇ୍ࣝぴ⏬㠃ࡢ㏣ຍ⾲♧ ࢹ࣮ࢱཷಙฎ⌮ࡀṇᖖ⤊ࡍࡿࠊཷಙࣇ୍ࣝぴ⏬㠃ࡀ㏣ຍ㸤⾲♧ࡉࢀࡲࡍࠋ ཷಙࣇ୍ࣝぴ⏬㠃ࡣཷಙࢹ࣮ࢱ㸯௳ࡘࡁ㸯⏬㠃㏣ຍࡉࢀࡲࡍࠋ ͤ ཷಙࣇ୍ࣝぴ⏬㠃ࡣ ཷಙࢹ࣮ࢱ㸯௳ࡘࡁ㸯⏬㠃㏣ຍࡉࢀࡲࡍࠋ ͤ 㑅ᢥࣇࣝྡࡣࢹ࣮ࢱ㏦ಙ㑅ᢥࣇࣝྡࡀ ࣜࢿ࣮࣒ࡉࢀࡓሙྜࣜࢿ࣮࣒๓ࡢྡ๓ࡀ⾲♧ࡉࢀࡲࡍࠋ ᩆᛴྥࡅᇶ♏ሗ࡛ࡣᖖ✵ⓑ࡞ࡾࡲࡍࠋ ͤ ⏬㠃ࡣ㛤Ⓨ୰ࡢࡶࡢ࡛࠶ࡿⅭࠊ㏦ಙࣇࣝྡࡀ [PO࡞ࡗ࡚࠸ࡲࡍࠋ ᐇ㝿ࡣࣇࣝ✀ูᛂࡌ࡚ኚࡉࢀࡓᙧᘧ࡛ࡢ ࣇࣝྡࡀ⾲♧ࡉࢀࡲࡍࠋ ;0/ᙧᘧࣇࣝ Ѝ ',&20ᙧᘧࣇࣝ Ѝ 3')ᙧᘧࣇࣝ Ѝ ձ ͤ ᮏࣉࣜࢆ⏝ࡍࡿ3&ࡢ⎔ቃࡼࡾࠊ ㏦ಙࣇࣝྡࢆࢡࣜࢵࢡࡋ࡚ࡶ ࣇࣝࡀ⾲♧ࡉࢀ࡞࠸ሙྜࡀ࠶ࡾࡲࡍࠋ ࡑࡢ㝿ࡣ3&ୖグͤࡢኚᚋࡢᙧᘧࣇࣝࢆᢅ࠺ ࣉࣜࢣ࣮ࢩࣙࣥࡢ⣣ࡅタᐃࢆ⾜ࡗ࡚ୗࡉ࠸ࠋ ղ ձ ཷಙࣇ୍ࣝぴ⏬㠃ࡢ㏦ಙࣇࣝྡࡢࣇࣝྡࢆࢡࣜࢵࢡࡍࡿࠊ ࣇࣝࡀᐇ⾜ࡉࢀ3&ࡢࣇࣝᙧᘧ⣣ࡅࡽࢀ࡚࠸ࡿࣉࣜࢣ࣮ࢩࣙࣥࡀ㉳ືࡋ࡚ࣇࣝࢆ⾲♧ࡋࡲࡍࠋ ղ ཷಙࣇ୍ࣝぴ⏬㠃ࢆ㛢ࡌࡿሙྜࠊ㛢ࡌࡿ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ 㻞㻣㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 (;ཷಙࠉᝈ⪅㏦ಙ࣓࣮ࣝ ་⒪ᶵ㛵ࡼࡾࢹ࣮ࢱཷಙࡀᐇ⾜ࡉࢀࡿࠊཷಙࢹ࣮ࢱࡢᝈ⪅㏻▱࣓࣮ࣝࡀ㏦ಙࡉࢀࡲࡍࠋ ࢱࢺࣝ㸸 ࢹ࣮ࢱཧ↷ࡢ࠾▱ࡽࡏ\\\\PPGGBKK00VV ͤ \\\\PPGGBKK00VVࠉ࣓࣮ࣝ㏦ಙฎ⌮᪥ ᮏᩥ㸸 ㉥ᯟ࡛ᅖࡲࢀࡓሗࡀཷಙࢹ࣮ࢱࡢሗ࡛ࡍࠋ ͤ ͤ ㏦ಙ⪅࣓࣮ࣝࢻࣞࢫࡣཧ↷ᶵ㛵࡞ࡾࡲࡍࠋ ᝈ⪅ࡼࡿ:HE⏝⪅ྥࡅ⏬㠃ࡽࡢ࣓࣮ࣝࢻࣞࢫⓏ㘓ࡀ⾜ࢃࢀ࡚࠸࡞࠸ሙྜࠊ࣓࣮ࣝࡣ㏦ಙࡉࢀࡲࡏࢇࠋ 㻞㻤㻌㻛㻌㻢㻜㻌䝨䞊䝆 125 3')ᙧᘧࣇࣝ -3(*ᙧᘧࣇࣝ 3')ᙧᘧࣇࣝ↓ኚ Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥ᧯స ᩆᛴྥࡅᇶ♏ሗⓏ㘓 ᩆᛴྥࡅࡢᇶ♏ሗࡢධຊධຊࢹ࣮ࢱࡢࢧ࣮ࣂ࣮㏦ಙฎ⌮ࢆ⾜࠸ࡲࡍࠋ ᩆᛴྥࡅᇶ♏ሗⓏ㘓⏬㠃ࡢ⾲♧ ձ ձ ⏬㠃ୖ㒊ࡢᩆᛴⓏ㘓ࢱࣈࢆࢡࣜࢵࢡࡋࡲࡍࠋ ͤ ⏬㠃ࢆ⾲♧ࡋ࡚࠸ࡿሙྜᚲせ࡞᧯స࡛ࡍࠋ ᪤⾲♧ࡉࢀ࡚࠸ࡿሙྜࡣᚲせ࠶ࡾࡲࡏࢇࠋ 㻞㻥㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᩆᛴྥࡅᇶ♏ሗࡢධຊ㸤Ⓩ㘓 ⏬㠃ࡢධຊ㡯┠ᚲせ㡯ࢆධຊࡋࠊࢧ࣮ࣂ࣮ࢹ࣮ࢱ㏦ಙࢆ⾜࠸ࡲࡍࠋ ͤୗ᪉ࢫࢡ࣮ࣟࣝ ձ ձ ձ ධຊࡋࡓෆᐜࢆⓏ㘓ࢧ࣮ࣂ࣮㏦ಙࡍࡿሙྜࠊⓏ㘓࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ධຊࡋࡓෆᐜࢆ࡚ࢡࣜࡍࡿሙྜࠊࢡࣜ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ᩆᛴྥࡅᇶ♏ሗⓏ㘓ᐇ⾜☜ㄆࢲࣟࢢࡢ⾲♧ ୖグձ࡛Ⓩ㘓࣎ࢱࣥࢆᢲୗࡋࡓሙྜࠊⓏ㘓ࢧ࣮ࣂ࣮㏦ಙฎ⌮ࡢᐇ⾜☜ㄆࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ ձ Ⓩ㘓ฎ⌮ࢆᐇ⾜ࡍࡿሙྜࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ Ⓩ㘓ฎ⌮ࢆ୰᩿ࡍࡿሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㻟㻜㻌㻛㻌㻢㻜㻌䝨䞊䝆 126 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 Ⓩ㘓ฎ⌮ᐇ⾜୰ࡢ⏬㠃⾲♧ Ⓩ㘓ࢧ࣮ࣂ࣮㏦ಙฎ⌮ࢆᐇ⾜୰ࡢሙྜࠊ⏬㠃ୖࡢ࣎ࢱࣥࡣ࡚⏝ྍ࡞ࡾࡲࡍࠋ ฎ⌮࣓ࢵࢭ࣮ࢪࡢ⾲♧ ࢹ࣮ࢱཷಙฎ⌮ࡀṇᖖ⤊ࡋࡓሙྜࠊฎ⌮ࢆ࿌ࡆࡿ࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ゎ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㻟㻝㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 Ⓩ㘓ᚋࡢ⏬㠃⾲♧ ධຊ್ࡣ࡚ࢡࣜࡉࢀࠊ་⒪ᶵ㛵ሗࡢึᮇ್ࡀタᐃࡉࢀࡓ⏬㠃ࡀ⾲♧ࡉࢀࡲࡍࠋ 㻟㻞㻌㻛㻌㻢㻜㻌䝨䞊䝆 127 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥ᧯స ᩆᛴྥࡅᇶ♏ሗཧ↷ ᩆᛴྥࡅᇶ♏ሗࢆ᳨⣴ࡋࠊࢹ࣮ࢱཷಙฎ⌮ࢆ⾜࠸ࡲࡍࠋ ᩆᛴྥࡅᇶ♏ሗཧ↷⏬㠃ࡢ⾲♧ ձ ձ ⏬㠃ୖ㒊ࡢᩆᛴⓏ㘓ࢱࣈࢆࢡࣜࢵࢡࡋࡲࡍࠋ ͤ ⏬㠃ࢆ⾲♧ࡋ࡚࠸ࡿሙྜᚲせ࡞᧯స࡛ࡍࠋ ᪤⾲♧ࡉࢀ࡚࠸ࡿሙྜࡣᚲせ࠶ࡾࡲࡏࢇࠋ 㻟㻟㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 デ⒪ᇶ♏ሗࡢ᳨⣴᮲௳タᐃ Ⓩ㘓ࡉࢀ࡚࠸ࡿᩆᛴྥࡅᇶ♏ሗࢆ᳨⣴ࡍࡿࡓࡵࡢ᮲௳タᐃࢆ⾜࠸ࡲࡍࠋ ձ ղ ձ ᝈ⪅ྡጣ ᝈ⪅ྡྡ ᝈ⪅,' ⏕ᖺ᭶᪥ 㸸 㸸 㸸 㸸 ᝈ⪅ࡢጣ࡛/,.(᳨⣴ࡍࡿሙྜࠊධຊࡋࡲࡍࠋ ᝈ⪅ࡢྡ࡛/,.(᳨⣴ࡍࡿሙྜࠊධຊࡋࡲࡍࠋ ᝈ⪅,'᳨࡛⣴ࡍࡿሙྜࠊධຊࡋࡲࡍࠋ ⏕ᖺ᭶᪥᳨࡛⣴ࡍࡿሙྜࠊධຊࡋࡲࡍࠋ ͤ ୖグࡢ㡯┠ࡣ௵ពࡢタᐃ㡿ᇦࡢⅭࠊ࡚ࡢ㡯┠ࢆタᐃࡍࡿᚲせࡣ࠶ࡾࡲࡏࢇࠋ ఱࡶධຊ㑅ᢥࡋ࡞࠸ሙྜࠊⓏ㘓ࡉࢀ࡚࠸ࡿ࡚ࡢᩆᛴྥࡅᇶ♏ሗࢆ⾲♧ࡋࡲࡍࠋ ղ ᳨⣴࣎ࢱࣥࢆᢲୗࡋ࡚ࡃࡔࡉ࠸ࠋ ୖグձࡢ᮲௳࡛ᩆᛴྥࡅᇶ♏ሗ᳨⣴ฎ⌮ࢆᐇ⾜ࡋࡲࡍࠋ 㻟㻠㻌㻛㻌㻢㻜㻌䝨䞊䝆 128 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᳨⣴⤖ᯝࡢ⾲♧ ୖグ࡛タᐃࡋࡓ᳨⣴᮲௳ヱᙜࡍࡿࢹ࣮ࢱࢆ᳨⣴⤖ᯝ୍ぴࣜࢫࢺ⾲♧ࡋࡲࡍࠋ 㻟㻡㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᳨⣴⤖ᯝࢹ࣮ࢱࡢ⾲♧ ᳨⣴⤖ᯝ୍ぴࡽࢹ࣮ࢱࢆ㑅ᢥࡋࠊᩆᛴྥࡅᇶ♏ሗࢆࢧ࣮ࣂ࣮ࡽཷಙࡋ⾲♧ࡋࡲࡍࠋ ձ ղ ձ ᳨⣴⤖ᯝ୍ぴࣜࢫࢺࡢཷಙࡍࡿࢹ࣮ࢱࡢ㑅ᢥ㡯┠ࢆࢡࣜࢵࢡࡋࠊࢳ࢙ࢵࢡ21≧ែࡋࡲࡍࠋ ղ ⾲♧࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ࢹ࣮ࢱཷಙฎ⌮ᐇ⾜☜ㄆࢲࣟࢢࡢ⾲♧ ୖグղࡢ᧯సࡼࡾฎ⌮ࡢᐇ⾜☜ㄆࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ࢹ࣮ࢱཷಙฎ⌮ࢆᐇ⾜ࡍࡿሙྜࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ࢹ࣮ࢱཷಙฎ⌮ࢆ୰᩿ࡍࡿሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㻟㻢㻌㻛㻌㻢㻜㻌䝨䞊䝆 129 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ฎ⌮࣓ࢵࢭ࣮ࢪࡢ⾲♧ ࢹ࣮ࢱཷಙฎ⌮ࡀṇᖖ⤊ࡋࡓሙྜࠊฎ⌮ࢆ࿌ࡆࡿ࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ゎ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ ཷಙࣇ୍ࣝぴ⏬㠃ࡢ㏣ຍ⾲♧㸤ࣇࣝ⾲♧ ࢹ࣮ࢱཷಙฎ⌮ࡀṇᖖ⤊ࡍࡿࠊཷಙࣇ୍ࣝぴ⏬㠃ࡀ㏣ຍ㸤⾲♧ࡉࢀࡲࡍࠋ ͤ ཷಙࣇ୍ࣝぴ⏬㠃ࡣ ཷಙࢹ࣮ࢱ㸯௳ࡘࡁ㸯⏬㠃㏣ຍࡉࢀࡲࡍࠋ ͤ 㑅ᢥࣇࣝྡࡣࢹ࣮ࢱ㏦ಙ㑅ᢥࣇࣝྡࡀ ࣜࢿ࣮࣒ࡉࢀࡓሙྜࣜࢿ࣮࣒๓ࡢྡ๓ࡀ⾲♧ࡉࢀࡲࡍࠋ ᩆᛴྥࡅᇶ♏ሗ࡛ࡣᖖ✵ⓑ࡞ࡾࡲࡍࠋ ͤ ⏬㠃ࡣ㛤Ⓨ୰ࡢࡶࡢ࡛࠶ࡿⅭࠊ㏦ಙࣇࣝྡࡀ [PO࡞ࡗ࡚࠸ࡲࡍࠋ ᐇ㝿ࡣࣇࣝ✀ูᛂࡌ࡚ኚࡉࢀࡓᙧᘧ࡛ࡢ ࣇࣝྡࡀ⾲♧ࡉࢀࡲࡍࠋ ;0/ᙧᘧࣇࣝ Ѝ ',&20ᙧᘧࣇࣝ Ѝ 3')ᙧᘧࣇࣝ Ѝ ձ ͤ 3')ᙧᘧࣇࣝ -3(*ᙧᘧࣇࣝ 3')ᙧᘧࣇࣝ↓ኚ ᮏࣉࣜࢆ⏝ࡍࡿ3&ࡢ⎔ቃࡼࡾࠊ ㏦ಙࣇࣝྡࢆࢡࣜࢵࢡࡋ࡚ࡶ ࣇࣝࡀ⾲♧ࡉࢀ࡞࠸ሙྜࡀ࠶ࡾࡲࡍࠋ ࡑࡢ㝿ࡣ3&ୖグͤࡢኚᚋࡢᙧᘧࣇࣝࢆᢅ࠺ ࣉࣜࢣ࣮ࢩࣙࣥࡢ⣣ࡅタᐃࢆ⾜ࡗ࡚ୗࡉ࠸ࠋ ղ ձ ཷಙࣇ୍ࣝぴ⏬㠃ࡢ㏦ಙࣇࣝྡࡢࣇࣝྡࢆࢡࣜࢵࢡࡍࡿࠊ ࣇࣝࡀᐇ⾜ࡉࢀ3&ࡢࣇࣝᙧᘧ⣣ࡅࡽࢀ࡚࠸ࡿࣉࣜࢣ࣮ࢩࣙࣥࡀ㉳ືࡋ࡚ࣇࣝࢆ⾲♧ࡋࡲࡍࠋ ղ ཷಙࣇ୍ࣝぴ⏬㠃ࢆ㛢ࡌࡿሙྜࠊ㛢ࡌࡿ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ 㻟㻣㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥ᧯స ᝈ⪅ㄆドሗⓏ㘓 ᝈ⪅㓄ᕸࡋࡓᝈ⪅ㄆド,'ࠊᝈ⪅,'ࡢ⣣ࡅⓏ㘓ࢆ⾜࠸ࡲࡍࠋ ᝈ⪅ㄆドሗⓏ㘓⏬㠃ࡢ⾲♧ ձ ͤ ་⒪ᶵ㛵ࡣᮏࣉࣜࢆ⏝ࡋ࡚࠸ࡿᶵ㛵ࡢྡ⛠ ࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ⏬㠃ୖ㒊ࡢᩆᛴⓏ㘓ࢱࣈࢆࢡࣜࢵࢡࡋࡲࡍࠋ ͤ ⏬㠃ࢆ⾲♧ࡋ࡚࠸ࡿሙྜᚲせ࡞᧯స࡛ࡍࠋ ᪤⾲♧ࡉࢀ࡚࠸ࡿሙྜࡣᚲせ࠶ࡾࡲࡏࢇࠋ 㻟㻤㻌㻛㻌㻢㻜㻌䝨䞊䝆 130 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᝈ⪅ሗࡢⓏ㘓 ᝈ⪅,'ᝈ⪅ㄆド,'ࢆ⣣ࡅⓏ㘓ࡋࡲࡍࠋ ձ ղ ճ ձ ᶵ㛵ẖࡢᝈ⪅,'ࢆධຊࡋ࡚ୗࡉ࠸ࠋ ղ ᝈ⪅㓄ᕸࠊࡲࡓࡣᝈ⪅ࡀ᪤ᣢࡗ࡚࠸ࡿᝈ⪅ㄆド,'ࢆධຊࡋ࡚ୗࡉ࠸ࠋ ճ ⣣ࡅⓏ㘓࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ᝈ⪅ㄆドሗⓏ㘓ᐇ⾜☜ㄆࢲࣟࢢࡢ⾲♧ ୖグճࡢ᧯సࡼࡾฎ⌮ࡢᐇ⾜☜ㄆࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ᝈ⪅ㄆドሗⓏ㘓ฎ⌮ࢆᐇ⾜ࡍࡿሙྜࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ᝈ⪅ㄆドሗⓏ㘓ฎ⌮ࢆ୰᩿ࡍࡿሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㻟㻥㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ฎ⌮࣓ࢵࢭ࣮ࢪࡢ⾲♧ ᝈ⪅ㄆドሗⓏ㘓ฎ⌮ࡀṇᖖ⤊ࡋࡓሙྜࠊฎ⌮ࢆ࿌ࡆࡿ࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ゎ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ ᝈ⪅ㄆドሗⓏ㘓ᚋࡢ⏬㠃 Ⓩ㘓ධຊࡋࡓ್ࡣ࡚ࢡࣜࡉࢀࡲࡍࠋ 㻠㻜㻌㻛㻌㻢㻜㻌䝨䞊䝆 131 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥ᧯స ྠព᭩Ⓩ㘓 ᝈ⪅ࡢྠព᭩ࢆⓏ㘓ࢧ࣮ࣂ㏦ಙࡋࡲࡍࠋ ྠព᭩Ⓩ㘓⏬㠃ࡢ⾲♧ ձ ͤ ྲྀᚓᶵ㛵ࡣᮏࣉࣜࢆ⏝ࡋ࡚࠸ࡿᶵ㛵ࡢྡ⛠ ࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ⏬㠃ୖ㒊ࡢᩆᛴⓏ㘓ࢱࣈࢆࢡࣜࢵࢡࡋࡲࡍࠋ ͤ ⏬㠃ࢆ⾲♧ࡋ࡚࠸ࡿሙྜᚲせ࡞᧯స࡛ࡍࠋ ᪤⾲♧ࡉࢀ࡚࠸ࡿሙྜࡣᚲせ࠶ࡾࡲࡏࢇࠋ 㻠㻝㻌㻛㻌㻢㻜㻌䝨䞊䝆 ᝈ⪅ሗࡢධຊ Ⓩ㘓ࡍࡿྠព᭩ࡢᝈ⪅ሗࢆධຊࡋࡲࡍࠋ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ձ ղ ճ մ ձ ղ ճ մ ᮏࣉࣜࢆ⏝ࡋ࡚࠸ࡿᶵ㛵ࡀᝈ⪅ᙜ࡚ࡓᝈ⪅,'ࢆධຊࡋ࡚ୗࡉ࠸ࠋ ᝈ⪅ࡢጣྡࢆධຊࡋ࡚ୗࡉ࠸ࠋ ᝈ⪅ࡢ⏕ᖺ᭶᪥ࢆすᬺ࡛ධຊࡋ࡚ୗࡉ࠸ࠋ ྠព᭩ࣇࣝࢆ㑅ᢥࡍࡿࡓࡵཧ↷࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ 㻠㻞㻌㻛㻌㻢㻜㻌䝨䞊䝆 132 Copyright(C)2010 by The University of Tokyo ྠព᭩ࣇࣝࡢ㑅ᢥ ୖグմࡢ᧯సࡼࡾࣇࣝ㑅ᢥࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ձ ղ ձ ᝈ⪅ࡀ⨫ྡࡋࡓྠព᭩ࢆ3')ᙧᘧࣇࣝኚࡋࡓࣇࣝࢆ㑅ᢥࡋ࡚ୗࡉ࠸ࠋ ղ 㑅ᢥࡋࡓࣇࣝࢆྠព᭩ࣇࣝࡍࡿሙྜࠊ㛤ࡃ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ྠព᭩ࣇࣝࡢ㑅ᢥࢆ୰᩿ࡍࡿሙྜࠊྲྀᾘࡋ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ͤ ⣬፹యࡢྠព᭩ࢆㄞࡳྲྀࡾࠊ3')ኚࡍࡿᶵ⬟ࡣᮏࣉࣜࡣ࠶ࡾࡲࡏࢇࠋ ู㏵ࠊࣉࣜࢣ࣮ࢩࣙࣥࢆ⏝ࡋ࡚సᡂࡋ࡚ୗࡉ࠸ࠋ 㻠㻟㻌㻛㻌㻢㻜㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ྠព᭩ࡢⓏ㘓 ୖグ࡛㑅ᢥࡋࡓࣇࣝࢆྠព᭩ࡋ࡚Ⓩ㘓ࢧ࣮ࣂ࣮㏦ಙࡋࡲࡍࠋ ձ ձ ⏬㠃ࡢෆᐜၥ㢟ࡀ↓ࡅࢀࡤࠊⓏ㘓࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ྠព᭩Ⓩ㘓ฎ⌮ᐇ⾜☜ㄆࢲࣟࢢࡢ⾲♧ ୖグճࡢ᧯సࡼࡾฎ⌮ࡢᐇ⾜☜ㄆࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ྠព᭩Ⓩ㘓ฎ⌮ࢆᐇ⾜ࡍࡿሙྜࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ྠព᭩Ⓩ㘓ฎ⌮ࢆ୰᩿ࡍࡿሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㻠㻠㻌㻛㻌㻢㻜㻌䝨䞊䝆 133 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ྠព᭩Ⓩ㘓୰ࡢ⏬㠃⾲♧ ྠព᭩Ⓩ㘓ࢧ࣮ࣂ࣮㏦ಙฎ⌮୰ࡣ⏬㠃ୖࡢ࡚ࡢ࣎ࢱࣥࡀ⏝ྍ࡞ࡾࡲࡍࠋ ฎ⌮࣓ࢵࢭ࣮ࢪࡢ⾲♧ ᝈ⪅ㄆドሗⓏ㘓ฎ⌮ࡀṇᖖ⤊ࡋࡓሙྜࠊฎ⌮ࢆ࿌ࡆࡿ࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ゎ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㻠㻡㻌㻛㻌㻢㻜㻌䝨䞊䝆 Ⓩ㘓ᚋࡢ⏬㠃⾲♧ ධຊ㑅ᢥࡋࡓ್ࡣ࡚ࢡࣜࡉࢀࡲࡍࠋ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 㻠㻢㻌㻛㻌㻢㻜㻌䝨䞊䝆 134 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ᆅᇦ་⒪㧗ᗘሗ㐃ᦠࢧ࣮ࣅࢫᐇドᐇ㦂ࢩࢫࢸ࣒ࠉࢡࣛࣥࢺࣉࣜࢣ࣮ࢩࣙࣥ᧯స ࣭⏝⪅ྥࡅ⏬㠃 ⏝⪅ᝈ⪅ࡀ⮬㌟ࡢࢹ࣮ࢱ㏦ཷಙᒚṔࢆཧ↷ࡍࡿⅭࡢ⏬㠃࡛ࡍࠋ ⏝⪅ྥࡅㄆド⏬㠃ࡢ⾲♧ ࣥࢱ࣮ࢿࢵࢺ࢚ࢡࢫࣉ࣮࣮࡛ࣟࣛୗグࡢ㹓㹐㹊ࡢ⏬㠃ࢆ⾲♧ࡋࡲࡍࠋ ㉳ື⏬㠃㹓㹐㹊㸸 KWWSVZZZPVF]KXWRN\RDFMSPHGLFLQI ͤ ͤ᧯సㄝ᫂᭩ࢆࢡࣜࢵࢡࡍࡿࠊᮏ᭩ࡀ㛤ࡁࡲࡍࠋ ͤ⏬ീࡢ85/ࡣ㛤Ⓨ⏝ࡢⅭࠊᐇ㝿ࡢ85/ࡣ␗࡞ࡾࡲࡍࠋ 㻝㻌㻛㻌㻝㻠㻌䝨䞊䝆 ͤ ࣉࣜࢣ࣮ࢩࣙࣥ㉳ື⏬㠃ࡢࢭ࢟ࣗࣜࢸ㆙࿌ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ࣉࣜࢣ࣮ࢩࣙࣥࡢド᫂᭩ࢆ᳨ド࡛ࡁ࡞࠸ሙྜࠊୗグࡢ࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ձ ࣉࣜࢣ࣮ࢩࣙࣥࢆ㉳ືࡍࡿሙྜࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ㏻ᖖࡣࡇࡕࡽ ࣉࣜࢣ࣮ࢩࣙࣥࡢ㉳ືࡋ࡞࠸ሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ 㻞㻌㻛㻌㻝㻠㻌䝨䞊䝆 135 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ⏝⪅ㄆド,'㸤ࣃࢫ࣮࣡ࢻධຊ㸤ࣟࢢ࢜ࣥ ་⒪ᶵ㛵ࡢྠព᭩ᥦฟ㓄ᕸࡉࢀࡓ⏝⪅ㄆド,'ࣃࢫ࣮࣡ࢻࢆධຊࡋࣟࢢ࢜ࣥࡋࡲࡍࠋ ձ ղ ճ ձ ⏝⪅ㄆド,'ࢆධຊࡋ࡚ୗࡉ࠸ࠋ ղ ⏝⪅ㄆドࣃࢫ࣮࣡ࢻࢆධຊࡋ࡚ୗࡉ࠸ࠋ ճ Ⓩ㘓࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ͤ ྠព᭩ࢆᥦฟࡋࡓ་⒪ᶵ㛵࡛⏝⪅ᝈ⪅ㄆドሗⓏ㘓ࡀࡋ࡚࠸࡞࠸ࠊࣟࢢ࡛࢜ࣥࡁࡲࡏࢇࠋ ࡑࡢ᪨ࢆ࿌ࡆࡿ࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡓሙྜࡣࠊ་⒪ᶵ㛵ࡢᢸᙜ⪅㐃⤡ࡋ࡚ୗࡉ࠸ࠋ 㻟㻌㻛㻌㻝㻠㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ࣓࣮ࣝࢻࣞࢫⓏ㘓 ึᅇ㉳ືࡲࡓࡣ࣓࣮ࣝࢻࣞࢫᮍⓏ㘓ࡢሙྜࠊ࣓࣮ࣝࢻࣞࢫⓏ㘓⏬㠃ࡀ⾲♧ࡉࢀࡲࡍࠋ ࣓࣮ࣝࢻࣞࢫࡢⓏ㘓ࢆ⾜ࡗ࡚ୗࡉ࠸ࠋ ͤ ,'ࡣୖグ࡛ධຊࡋࡓᝈ⪅ㄆド,'ࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ղ ձ ་⒪ᶵ㛵ࡼࡿデ⒪ࢹ࣮ࢱཧ↷ࡢ㏻▱࣓࣮ࣝࡢᐄඛ࡞ࡿ࣓࣮ࣝࢻࣞࢫࢆධຊࡋ࡚ୗࡉ࠸ࠋ ղ ධຊࡋࡓ࣓࣮ࣝࢻࣞࢫࢆⓏ㘓ࡍࡿሙྜࠊⓏ㘓࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ࣓࣮ࣝࢻࣞࢫࢆⓏ㘓ࡋ࡞࠸ሙྜࠊ࢟ࣕࣥࢭࣝ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋࡑࡢሙྜࠊୖグࡢ⏬㠃ᡠࡾࡲࡍࠋ 㻠㻌㻛㻌㻝㻠㻌䝨䞊䝆 136 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ࣓࣮ࣝࢻࣞࢫⓏ㘓ᐇ⾜☜ㄆࢲࣟࢢࡢ⾲♧ ୖグ㸱࡛Ⓩ㘓࣎ࢱࣥࢆᢲୗࡋࡓሙྜࠊ࣓࣮ࣝࢻࣞࢫⓏ㘓ฎ⌮ࡢᐇ⾜☜ㄆࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ࣓࣮ࣝࢻࣞࢫⓏ㘓ฎ⌮ࢆᐇ⾜ࡍࡿሙྜࠊ2.࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ࣓࣮ࣝࢻࣞࢫⓏ㘓ฎ⌮ࢆ୰᩿ࡍࡿሙྜࠊ࢟ࣕࣥࢭࣝ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ ⏝⪅ྥࡅࢹ࣮ࢱ୍ぴ⏬㠃ࡢ⾲♧ ࣓࣮ࣝࢻࣞࢫⓏ㘓ࡀࡍࡿࠊᝈ⪅ྥࡅ୍ぴ⏬㠃ࡀ⾲♧ࡉࢀࡲࡍࠋ ͤ ࣓࣮ࣝࢻࣞࢫࡀⓏ㘓῭ࡳࡢሙྜࠊୖグࡢㄆド⏬㠃ࡽᮏ⏬㠃⛣ືࡋࡲࡍࠋ ͤ ࢹ࣮ࢱ୍ぴࠉ≧ែ㡯┠ࡢព ᮍㄞ ᪤ㄞ ๐㝖῭ ๐㝖౫㢗῭ 㸸 㸸 㸸 㸸 ㏦ಙඛࡢ་⒪ᶵ㛵࡛ཷಙࡉࢀ࡚࠸ࡲࡏࢇࠋ ㏦ಙඛࡢ་⒪ᶵ㛵࡛ཷಙࡉࢀࡲࡋࡓࠋ ㏦ಙඖࡢ་⒪ᶵ㛵࡛๐㝖ࡉࢀࡲࡋࡓࠋ ࢹ࣮ࢱ๐㝖౫㢗ࡀᐇ⾜῭ࡳ࡛ࡍࠋ 㻡㻌㻛㻌㻝㻠㻌䝨䞊䝆 ࢹ࣮ࢱ๐㝖౫㢗 ་⒪ᶵ㛵ࡼࡗ࡚㏦ཷಙࡉࢀ࡚࠸ࡿࢹ࣮ࢱࡢ๐㝖౫㢗ࢆฟࡋࡲࡍࠋ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ͤ ࢹ࣮ࢱ୍ぴࠉ≧ែ㡯┠ࡢ⾲♧ࡀ ๐㝖῭ࡲࡓࡣ๐㝖౫㢗῭ࡢࢹ࣮ࢱࡣ㑅ᢥ࡛ࡁࡲࡏࢇࠋ ձ ղ ձ ࢹ࣮ࢱ୍ぴࡽ๐㝖ࡋࡓ࠸ࢹ࣮ࢱࡢ㑅ᢥ㡯┠ࢆࢡࣜࢵࢡࡋࠊࢳ࢙ࢵࢡ21≧ែࡋ࡚ୗࡉ࠸ࠋ ࢳ࢙ࢵࢡࡣ」ᩘࢹ࣮ࢱࡢ㑅ᢥࡀྍ⬟࡛ࡍࡀࠊ๐㝖౫㢗ࡢྲྀᾘࡋࡣฟ᮶࡞࠸ࡢ࡛ࠊㄗ㑅ᢥࡈὀពୗࡉ࠸ࠋ ղ ๐㝖౫㢗࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ 㻢㻌㻛㻌㻝㻠㻌䝨䞊䝆 137 Copyright(C)2010 by The University of Tokyo ๐㝖౫㢗ฎ⌮ᐇ⾜☜ㄆࢲࣟࢢࡢ⾲♧ ๐㝖౫㢗ฎ⌮ࡢᐇ⾜ࢆ☜ㄆࡍࡿࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ձ ๐㝖౫㢗ࢆᐇ⾜ࡍࡿሙྜࠊ2.࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ๐㝖౫㢗ࢆ୰᩿ࡍࡿሙྜࠊ࢟ࣕࣥࢭࣝ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㸬๐㝖౫㢗ฎ⌮ࡼࡿ≧ែ㡯┠ࡢ⾲♧ ୖグձ࡛2.࣎ࢱࣥࢆᢲୗࡋࠊ๐㝖౫㢗ฎ⌮ࡀṇᖖ⤊ࡋࡓሙྜࠊ⏬㠃࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ 㻣㻌㻛㻌㻝㻠㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ࣓࣮ࣝࢻࣞࢫࡢኚ᭦⏬㠃ࡢ⾲♧ ึᅇ㉳ືⓏ㘓ࡋࡓ࣓࣮ࣝࢻࣞࢫࢆኚ᭦ࡍࡿⅭࡢ⏬㠃ࢆ⾲♧ࡋࡲࡍࠋ ⏝⪅ྥࡅࢹ࣮ࢱ୍ぴ⏬㠃ࡽ᧯సࢆ⾜࠸ࡲࡍࠋ ձ ձ ⏬㠃ୗ㒊ࡢ࣓࣮ࣝࢻࣞࢫࡢኚ᭦ࣜࣥࢡࢆࢡࣜࢵࢡࡋࡲࡍࠋ 㻤㻌㻛㻌㻝㻠㻌䝨䞊䝆 138 Copyright(C)2010 by The University of Tokyo ᪂࣓࣮ࣝࢻࣞࢫࡢධຊ㸤Ⓩ㘓 ୖグࡢ᧯సࡼࡾ࣓࣮ࣝࢻࣞࢫⓏ㘓⏬㠃ࡀ⾲♧ࡉࢀࡲࡍࠋ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ͤ ࣓࣮ࣝࢻࣞࢫධຊ㡯┠ࡣⓏ㘓῭ࡳ࣓࣮ࣝࢻࣞࢫࡀ ⾲♧ࡉࢀࡲࡍࠋ ձ ղ ձ ኚ᭦ࡍࡿ࣓࣮ࣝࢻࣞࢫࢆධຊࡋ࡚ୗࡉ࠸ࠋ ղ ࣓࣮ࣝࢻࣞࢫኚ᭦ࢆᐇ⾜ࡍࡿሙྜࠊⓏ㘓࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ࣓࣮ࣝࢻࣞࢫኚ᭦ࢆ୰᩿ࡍࡿሙྜࠊ࢟ࣕࣥࢭࣝ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋࠉͤ⏝⪅ࢹ࣮ࢱ୍ぴ⏬㠃⛣ືࡋࡲࡍࠋ 㻥㻌㻛㻌㻝㻠㻌䝨䞊䝆 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ࣓࣮ࣝࢻࣞࢫኚ᭦ฎ⌮࣓ࢵࢭ࣮ࢪࡢ⾲♧ ୖグձ࡛Ⓩ㘓࣎ࢱࣥࢆᢲୗࡋࡓሙྜࠊ࣓࣮ࣝࢻࣞࢫኚ᭦ฎ⌮ࡀṇᖖࡍࡿࠊ⏬㠃࣓ࢵࢭ࣮ࢪࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ձ ⏝⪅ྥࡅࢹ࣮ࢱ୍ぴ⏬㠃ᡠࡿሙྜࠊ࢟ࣕࣥࢭࣝ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ Ⓩ㘓࣎ࢱࣥࢆᢲୗࡍࡿࠊ⏬㠃ࡢෆᐜ࡛ᗘࠊ࣓࣮ࣝࢻࣞࢫኚ᭦ฎ⌮ࢆᐇ⾜ࡋࡲࡍࠋ 㻝㻜㻌㻛㻌㻝㻠㻌䝨䞊䝆 139 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ࢩࢫࢸ࣒⏝ྠព᭩ࡢ᧔ᅇ⏬㠃ࡢ⾲♧ ࢩࢫࢸ࣒⏝ྠពྠព᭩ࢆᥦฟࡋࡓ་⒪ᶵ㛵ᑐࡋ࡚ࠊྠពࡢ᧔ᅇࢆ⾜࠺⏬㠃ࢆ⾲♧ࡋࡲࡍࠋ ᝈ⪅ྥࡅࢹ࣮ࢱ୍ぴ⏬㠃ࡽ᧯సࢆ⾜࠸ࡲࡍࠋ ձ ձ ⏬㠃ୗ㒊ࡢࢩࢫࢸ࣒⏝ྠពࡢ᧔ᅇࣜࣥࢡࢆࢡࣜࢵࢡࡋ࡚ୗࡉ࠸ࠋ 㻝㻝㻌㻛㻌㻝㻠㻌䝨䞊䝆 ࢩࢫࢸ࣒⏝ྠព᧔ᅇ⏬㠃ࡢ⾲♧ ୖグձࡢ᧯సࡼࡾࠊࢩࢫࢸ࣒⏝ྠព᧔ᅇ⏬㠃ࡀ⾲♧ࡉࢀࡲࡍࠋ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 㻝㻞㻌㻛㻌㻝㻠㻌䝨䞊䝆 140 Copyright(C)2010 by The University of Tokyo 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ࢩࢫࢸ࣒⏝ྠព᧔ᅇࡢ᧯స ࢩࢫࢸ࣒⏝ྠព᧔ᅇ⏬㠃ࡀ⾲♧ࡉࢀࡿࡢ࡛ࠊ᧔ᅇࡍࡿᶵ㛵ࢆ㑅ᢥࡋࡲࡍࠋ ձ ղ ձ ࢹ࣮ࢱ୍ぴࡽྠព᭩ࢆ᧔ᅇࡍࡿࢹ࣮ࢱࡢ㑅ᢥ㡯┠ࢆࢡࣜࢵࢡࡋࠊࢳ࢙ࢵࢡ21≧ែࡋ࡚ୗࡉ࠸ࠋ ղ ᧔ᅇ࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ 㸬ྠព᭩᧔ᅇฎ⌮ᐇ⾜☜ㄆࢲࣟࢢࡢ⾲♧ ୖグղࡢ᧯సࡼࡾฎ⌮ࡢᐇ⾜☜ㄆࢲࣟࢢࡀ⾲♧ࡉࢀࡲࡍࠋ ձ ྠព᭩᧔ᅇฎ⌮ࢆᐇ⾜ࡍࡿሙྜࠊࡣ࠸࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ྠព᭩᧔ᅇฎ⌮ࢆ୰᩿ࡍࡿሙྜࠊ࠸࠸࠼࣎ࢱࣥࢆᢲୗࡋ࡚ୗࡉ࠸ࠋ ձ 㻝㻟㻌㻛㻌㻝㻠㻌䝨䞊䝆 ྠព᭩᧔ᅇᚋࡢ⏬㠃⾲♧ 㑅ᢥࡋࡓ་⒪ᶵ㛵ࡢࢹ࣮ࢱࡀࢹ࣮ࢱ୍ぴࡼࡾ๐㝖ࡉࢀࡲࡍࠋ 㼙㼑㼐㼕㼏㼕㼚㼒᧯స䝬䝙䝳䜰䝹㼋㻜㻞㻚㼤㼘㼟 ձ ձ ⏝⪅ྥࡅࢹ࣮ࢱ୍ぴ⏬㠃ᡠࡿሙྜࠊ⏬㠃ୗ㒊ࡢᝈ⪅ྥࡅࢹ࣮ࢱ୍ぴࣜࣥࢡࢆࢡࣜࢵࢡࡋ࡚ୗࡉ࠸ࠋ 㻝㻠㻌㻛㻌㻝㻠㻌䝨䞊䝆 141