openEHR の最新状況と 米国での EHR の現状調査
openEHR の最新状況と 米国での EHR の現状調査
調査報告書
2009 年 1 月 30 日
特定非営利活動法人
日本医療ネットワーク協会
調査報告
平成 20 年 6 月 6 日付けで取り交わしました、調査・コンサルティング業務委託契約書「openEHR の最新状況と米国での EHR の現状調査」に基づき、以下の調査を行いましたので、ご報告いたします。
【成果物】
1. 「openEHR の最新状況と米国での EHR の現状調査」調査報告書
～第一分冊：米国での EHR の現状調査～
2. 「openEHR の最新状況と米国での EHR の現状調査」調査報告書
～第二分冊：openEHR の最新状況
【調査概要】
第一部は、米国での EHR の現状について調査結果をまとめた。
これは、2008 年 10 月に、６名で組織した調査チームがボストン（ベス・イスラエル病院）とクリーブランド（クリーブランドクリニック）を訪れ、病院、システム、組織等に関する調査を行い、現地担当者と長時間に渡る意見交換を行い、後にこれを整理したものである。
第二部は、openEHR の最新状況に関する調査報告である。
この調査のために、2008 年度には、５月と１１月に openEHR の実質的な開発の中心的役割を果たしている、オーストラリアの Ocean Informatics Ltd. の技術者３名を招聘し、openEHR に関する情報を提供していただくとともに、様々な議論を行った。現時点では、日本における openEHR の具体的アウトプットは乏しいものの、今後は大きな影響が予想される。
openEHR の最新状況と 米国での EHR の現状調査
調査報告書
～第一分冊：米国での EHR の現状調査～
2009 年 1 月 30 日
特定非営利活動法人
日本医療ネットワーク協会
目 次
1 米国における EHR の現状 1
1.1 緒言 1
1.2 クリーブランドクリニック（Cleveland Clinic） 3
1.2.1 視察概要 3
1.2.2 クリーブランドクリニックとその組織 3
1.2.3 eCleveland Clinic 11
1.2.4 Google Health との連携 38
1.2.5 規格 51
1.3 ベスイスラエル病院（Xxxx Xxxxxx Deaconess Medical Center） -- 53
1.3.1 視察概要 53
1.3.2 ベスイスラエル病院 54
1.3.3 PatientSite 55
1.3.4 EHR の PatientSite 以外への利用状況 59
1.3.5 Google Health との連携 60
1.3.6 連携パートナーの動向 66
1.3.7 RHIO 67
1.3.8 規格 69
1.3.9 米国の医療行政などの動向 71
1.3.10 EHR の今後 72
1.1 緒言
Google Health に代表される患者向けの医療情報サービス（EHR/PHR）の現状と今後の動向を探るため、米国でも有数の規模を誇るクリーブランドクリニック、ベス・イスラエル・ディーコネス・メディカルセンター（以下「ベスイスラエル病院」）を訪問し、病院情報システム、PHR などに関する調査と担当者との議論を行った。訪問前の我々の関心事は以下の２点であった。
１） EHR/PHR、つまり、グーグルやマイクロソフト等による外部ストレージを介した患者向けの医療情報提供サービスの実態
２） PHR に使われる医療情報規格の現状と将来
しかし、実際に訪れてみると、米国を代表する病院であるこの２施設では、（ある意味当たり前であるが）イントラネット（病院情報システム）の構築に大半の資源をつぎ込んでおり、外部医療機関や患者に対しては、「イントラネットの延長」としてサービスを提供している。これは日本ではごく少数の事例を除いて、まだ見られない方法である。「イントラネットの延長」とは、Web 技術を用いて、主として内部サービスである「電子カルテ」を外部医療機関に有料で提供したり、外部のクリニックや患者に無料で提供したりすることであり、このサービスは、想像を超えてリッチなコンテンツを提供していた。明らかに関連医療機関、顧客（患者）を「囲い込む」戦略であると思われた。
では、そのような状況下で、なぜグーグルやマイクロソフトのオープンなサービスとの連携が必要となるのだろうか？その点が、我々は非常に奇異に思えるほど、囲い込み的サービスは充実していたのである。彼らは、オープン性、つまり患者がグーグルなどのアカウントを使ってデータを取り込み、これを他の医療グループに「持ち出す」ことを許す事によって、逆に彼らの価値を高めて患者獲得につながり、今後このような患者へのサービスを提供できない病院は取り残されるであろう、と言っている。詳細は本文を参照されたい。北米の「勝ち組」的な２つの医療機関の実態を見て、ヨーロッパや日本で発展途上にある連携医療との戦略の違いを感じざるを得ない。盛んに指摘されるように、北米における「医
療の分断: fragmentation in medicine」は、明らかに情報システムにも影響を与え、彼らの発想は日本やヨーロッパの「連携」とは異なり、それぞれのプライベートシステムの「拡張」が基本になっているように感じられたのである。
北米の医療機関は、連携に必要な情報規格についても、ヨーロッパとはかなり異なる考え方を持っているようである。2008 xxに ISO 規格となった openEHR に関する理解は低く、基本的に CDA rel.2を軸に動いている。ただ、ASTM（米国材料試験協会；American Society for Testing and Materials）が策定した CCR (Continuity of Care Record)をグーグルが採用し、CCR の CDA 版である CCD (Continuity of Care Document)をマイクロソフトが採用。一方で連邦政府は CDA を採用するという、大変混沌とした状況でもある。現時点では市場原理に委ねる形になっており、今後の推移が注目されるが、長期的に見て、openEHR の影響は避けられないと思われる。
1.2 クリーブランドクリニック
1.2.1 視察概要
視察日：2008 年 10 月 24 日（金）
視察先：オハイオ州クリーブランド クリーブランドクリニックメインキャンパス会議相手：C. Xxxxxx Xxxxxx, MD/MBA：Chief Information Officer
Xxxxxx Xxxxxxx, MBA：eCleveland Clinic Manager
図 1 Dr. Xxxxxx と視察メンバー
見学先：心臓血管研究所（Heart & Vascular Institute） 透析センター（Xxxxxxxx Urological & Kidney Institute）
1.2.2 クリーブランドクリニックとその組織
1.2.2.1 クリーブランドクリニックの概要
クリーブランドクリニックは、1921 年にオハイオ州クリーブランドに設立された由緒ある私立の非営利の病院であり、現在はクリーブランドにあるメインキャンパスの他に、フロリダやカナダのトロント、アラブ首長国連邦のアブダビに直営病院を、オハイオ州内に 17か所のファミリー病院を持ち、グループ全体で医療事業を展開している。この病院は、全米にある約 6,000 病院の中で、第 4 位にランキングされており、とくに心臓疾患において
は 1995 年以降連続して全米第 1 位の病院の評価を受けている（X.X.Xxxx & World Report の調査による）。この病院には医師と科学者が合わせて約 1,800 人おり、2007 年の年間の外来患者数は全米および世界80 か国以上の国から300 万人を超え、入院患者数は約11 万2000人、手術件数は約 23 万 1000 件、救急患者数は約 39 万人という巨大な規模を誇っている（数はいずれも延べ数）。この病院の研究組織は多くの医療革新に取り組んでおり、著名な例としては、世界初の冠動脈バイパス手術や世界初の喉頭の移植などがあり、現在は遺伝子分野に重点を置いて取り組んでいる。
メインキャンパスには 140 エーカーの広大な敷地の中に 37 の建物がある。
図 2 メインキャンパスの全景（模型）
Xxxxxx and Xxxxxx Xxxxxx Family Pavilion は 2008 年に完成し、そこには病院の総合受付があるとともに、心臓血管研究所が 10 月に開院された。
図 3 Xxxxxx and Xxxxxx Xxxxxx Family Pavilion
図 4 Xxxxxx and Xxxxxx Xxxxxx Family Pavilion の総合受付ロビー
心臓血管研究所には最新の機器を備えた手術室や病室があり、特に ICU は 110 床もある。全館にワイヤレスネットワークが構築され、病院内の情報のやり取りを行っている。バッテリーとともに専用ワゴンに搭載された可動式コンピュータは ICU には 1 部屋に 1 台、回復室には 2 部屋に 1 台の割合で配置されている。各部屋のベッドサイドにはモニター用のディスプレイが設置され、壁のユニット内には酸素などの配管が配置されていてスライド式の扉を開けるとアクセス可能となる設計になっている。回復室には付添の家族のためのベッドが壁面に組み込まれており、通常はベンチとして機能している。各病棟には患者サービス用の部屋があり、外部で作られた食事がこの部屋に運び込まれ、最終的な調理や調整が行われたうえで配膳されるようになっている。Xxxxxx and Xxxxxx Xxxxxx Family Pavilion の近くには 4,000 台を収容できる駐車場が新設されており、その地下に物流センターが作られる予定で、各建物の間にトンネルを通し、ロボットを使った自動運搬ができるように考えられている。最上階にはカフェテリアがあり、素晴らしい眺めを楽しむことができるようになっている。
図 5 心臓カテーテル室
図 6 ICU
図 7 手術予定を表示するディスプレイ
図 8 術後の回復室
図 9 可動式コンピュータ（下部にバッテリーを装備）
図 10 建物間の渡り廊下
図 11 Xxxxxx and Xxxxxx Xxxxxx Family Pavilion の屋上よりダウンタウンを望む左手には 4,000 台収容の駐車場が見える
Xxxxxx and Xxxxxx Xxxxxx Family Pavilion の後方に位置するキャンパス内で最も高い建物は、これも 2008 年に完成した Xxxxxxxx Tower で、ここでは最新施設を備える透析センターの開院工事が進められている。
図 12 Xxxxxxxx Tower（写真左手）
図 13 透析室（工事中）
医療事業はグループ全体で運営されており、意志決定とそれを実行する三つの組織が機能している。
第一は、エグゼクティブチームと呼ばれるもので、全チーフオフィサーとスタッフの長で構成されており、グループ全体の戦略を決定する。
第二は、医療執行評議会と呼ばれるもので、16 部門の各診療長と全チーフオフィサーで構成されており、グループ全体の運営計画を決定する。
第三は、計画の実行部門で、CIO である Dr. Xxxxxx の下に約 850 名のスタッフがおり、 グループ全体に亘る情報システム（経営システム、診療システム、業務システム）を構築、配備、運営している。
1.2.3 eCleveland Clinic
【背景】
A. 米国における医療情報交換の現状
医療情報の相互運用性（interoperability）は大変重要であると誰もが考えており、米国でもこれまで数多くの相互運用性に関する戦略が検討されてきた。3 年程前に、米国内に相互運用性を構築するための戦略を考える「系統的な相互運用性のための委員会」と称するものが米国議会内に設置された。その戦略に関するドキュメントはウェブ上で見ることができるが、これに対してふたつのことが言える。ひとつ目は、相互運用性によってもたらされる価値、特に患者に対してもたらされる価値を明確にすることが重要であり、ふたつ目は、標準化推進のためのインフラを連邦政府内に作り上げるということであった。しかし、その戦略では実際にデータ変換する部分はデザインされなかった。そして、戦略のデモンストレーションが計画された。それは、州単位で情報連携する RHIO （Regional Health Information Organization）であり、データ変換する部分は民間部門に投げられた。連邦政府が行ったことは、単に価値を見せるためのデモ的なデータ変換に過ぎず、実際にデータ変換されることはなかった。また、2008 年 9 月に突然ワシントン DC でデモンストレーション行われ、クリーブランドクリニックは 17 の州からプロバイダを連れて行き、全プロバイダ間のリアルタイムな情報変換の実演を行った。しかし、それは単なるデモンストレーションだけで終わってしまった。もうひとつ、デモンストレーションが 2008 年 12 月に向けて計画されていて、前回行われなかったいくつかのシナリオが実施される予定である。
B. eCleveland Clinic 開発の経緯
クリーブランドクリニックでは 2000 年頃に、情報技術の新しい活用方法を考え始め、患者へいかに医療を提供するか、そして病院内部の毎日の業務をいかに行うか、についてパラダイムをxx的に変えるために情報技術を活用することを目標に定めた。患者や非雇用の医師にもツールとして使ってもらうと同時に、末端の全てのデータを集め、医療の発展のために新しい知識を生み出していくことや医療教育活動を内部から支援することに使うことにした。クリーブランドクリニックではこの目標達成のために eCleveland Clinicと呼ぶ大規模な医療情報システムを作りあげた。
米国では一般的に病院は病院として、医療業務は医療業務として活動は分離されており、大学が医学校を所有している。しかし、これとは異なり、クリーブランドクリニックはグループとして活動をしており、医師グループはグループの全ての資産を所有することができるようになっている。医師グループは病院を所有し、医療業務を所有し、研究所を所有し、医学校を所有している。
【eCleveland Clinic の概要】
A. eCleveland Clinic の構成
eCleveland Clinic は、ふたつの大きなカテゴリーに分けられる一連のプログラムである。
図 14 eCleveland Clinic の構成
ひとつめは医療を提供する側（Provider）のカテゴリーであり、以下の構成になっている。 MyPractice
Dr.Connect
MyPractice・Community eResearch
ふたつめは医療を受ける患者側（Patient）のカテゴリーであり、以下の構成になっている。
MyChart MyConsult VirtualVisit MyMonitoring
このプログラムは「すべての人に対してひとつのツールを」ということを考えて作られており、中味は同じで、使う人によって見せ方を変えるように設計されている。
a) MyPractice
図 15 MyPractice
MyPractice は電子カルテ（EMR）システムであり、ひとつのツールを医師、看護師、受付、スケジュール管理者、研修医、研究者、そして病院内の患者（救急外来患者および入院患 者）も使用する。ただし、使用する人が誰であるかによってその機能は限定される。例え ば、受付は来院した患者と応対し、患者の保険情報と自宅の住所を確かめるだけである。 スケジュール管理者は、患者からの電話を受けて予約日を登録するだけである。スケジュ ール管理者は医師と同じシステムを使用しているが、日程表と予約登録だけしか見ること はできない。医師はすべての医療情報を見ることができ、看護師は医師とは少し違うがほ ぼ同じ情報を見ることができる。患者には見せるものを限定している。この電子カルテシ ステムにはあらかじめ広範囲の定義が施されている。
このシステムを使用する医師は約 5,800 人いて、約 2,000 人がクリーブランドクリニック
が雇用している医師であり、残りの約 3,800 人が他の病院で毎日コンピュータを使用し、このシステムを時々利用する医師である。ツールはクリーブランドクリニックの各階とすべての関連する病院に配備されている。クリーブランドクリニックは全米第 4 位の規模の大学院医学教育プログラムを持っており、そこの研修医やフェローも全員同じシステムを使用している。また、クリーブランドクリニックには 35 人程の小さな医学校があり（７月に入学）、医学生も全員同じシステムを使用し、すべての教育はオンラインで行われて
いる。調剤システムも同じシステムの見方を変えただけのもので、モジュールは違うが同じデータベースを使っている。
約 31,000 人がこのシステムを利用しており、その中で約 3 分の 1 の 7,400 から 7,500 人
が毎日同時刻にログインしている。MyPractice の 2008 年 9 月時点でのその他の状況は、
患者約 550 万人分のデータベースがあり、昨年 1 年間で累計約 300 万件の処方箋を作成し、
約 300 万件のオーダーが出された。そして、約 4 億件の患者に関するデータエレメントを所有している。
MyPractice は医師の視点から作られた様々な特徴を持っている。救急外来患者の場合は、このシステムを使って医師は患者とお互いに（電子メールではない）会話ができる。また、スケジュール管理者が使用する日程表は医師が使用する日程表と同じものであり、スケジ ュール管理者が日程を変更した場合はこの日程表はリアルタイムで変更される。どこでこ のシステムが使用されても、すべての結果がこのシステムに戻るようになっている。この システムには医師が全てのノートを書き込み、それが医師のオーダーエントリーとなる。
患者向けの機能は救急外来患者向けと入院患者向けの 2 種類があり、救急外来患者向けの機能は以下の通りである。
図 16 救急外来患者向けの機能
Messaging 患者から医師へのメッセージング Schedule 診療スケジュールの確認と予約 Results 検査結果の閲覧
Documentation ドキュメンテーション（例えばプログレスノートなど） Physician Order Entry コンピュータによる医師のオーダーエントリー
外来のオーダーエントリーは米国では一般的ではない Best Practice Alerts 最善な診療に関する警告（例えば薬の相互作用など）
図 17 薬の相互作用についての警告
図 18 年齢、性別等に基づく警告
ここには、患者に対してどのようなベストのケアをしたらいいかについての医師の勧告に基づいたルールを書き込むことができるようになっている。入院患者向けの機能は救急外来患者向けと同じシステムを使っているが、見せ方を少し変えている。
図 19 入院患者向けの機能
Inpatient census 入院情報：入院患者にはスケジュールは不要で、どこのベッドに患者がいるかが分かればいい
All Results 検査結果：これは基本的に救急外来患者向けとの間の区別はない
図 20 検査結果
検査結果は、言ってみれば、電子的なバスケットのような入れ物に入って医師の元へ届けられる。例えば、検査結果に赤いマークがついていなければ正常であり、もし、異常があれば、追加の検査を受けるメッセージが送られてくる。
Medication administration record 投薬記録
入院患者の方が救急外来患者より詳細である Vital signs and I&O バイタルサインとインプットアウトプット記録 Documentation オンラインドキュメンテーション
図 21 オンラインドキュメンテーション
入力はオンラインで行われ、以下の 3 通りの入力方法がある
・タイプ入力
・テンプレートを使った入力
・電話でのディクテーション
ディクテーションは音声認識を使う外部業者に委託している。従って、医師の元にはすでにタイプされたものが届けられ、医師は音声を聞きながら内容を確かめるだけでいいようになっている。また、医師も音声認識システムを持っていて、それを使って直接ディクテーションを行う場合もある。この音声認識を使ったディクテーションは 2008 年 7 月に試
行を始めたばかりであり、約 60 人の医師が実際に使用している、そして 2008 年末までに
この試行を完了させる予定である。これがうまく行けば、高い費用を払っている外部委託を止めることができるようになる。
Computerized Physician Order Entry コンピュータによる医師のオーダーエントリー
（CPOE）
図 22 コンピュータによるオーダーエントリー
コンピュータによる医師のオーダーエントリーでは、医師は何かオーダーするときに全てをタイプ入力しなくてもいいようになっている。最初の 2～3 文字をタイプすれば、候補が表示され、そこから選ぶだけでいい。そうすることによって、誤ったオーダー（例えば処方の数値を間違えることなど）を避けることができる。このことは診断においても言えることであり、診断も全てコード化されている。このオーダーエントリーの中には慢性的な問題のリストが記載されていて、その患者がどういう医学的問題を抱えていて、なぜここに入院しているのかが分かるようになっている。
MyPractice には薬剤の相互作用に関するインテリジェントな機能が入っている。ある患者に新しい薬が追加されたときに、相互作用があれば自動的に、重大な問題となるレベルも含めて、そのことを知らせてくれる。このシステムはもうひとつインテリジェントな機能を持っており、あるルールをバックグランドで走らせている。患者の性別、年齢、診断内容から、患者が健康を維持するためにやらなければならないことのリストが、医師へ直
接届けられる。例えば、年に 1 回マンモグラムを受けなければならないコレステロール値が高い女性患者の場合、一定の間隔でコレステロールのスクリーニングを受けなければならない、と表示される。もし、この表示が出なければ、この検査を受ける必要はない。 クリーブランドクリニックと連携している病院は、9 年前までは完全に独立した病院であり、お互いに競争していた。クリーブランドクリニックはこれらの病院を買収し、より良い医療を提供するために、そのリソースを再配置した。メインキャンパスで行ったことのいくつかをこれらの地域病院に移した。
ファミリー病院では準専門医による一次診断が行われる。ファミリー病院は、患者の自宅から 4 マイル以内にある場所を選んだ。完全ではないが、患者を病院に近づけるための一種の市場へのチャレンジである。ここで診断を受けることは、次の専門医に診断を受けることへの入口になる。すべての直営病院とすべてのファミリー病院は全く同じツールを持っており、これにより完全な医療事業が可能になっている。
図 23 クリーブランドクリニックグループ病院
eCleveland Clinic を動かしているメインコンピュータシステムはメインキャンパスの近くにあり、バックアップセンターはフィラデルフィアにある。
b) Dr.Connect
クリーブランドクリニックでは、この病院に来る毎年 10 万人以上の患者を照会する約 1万人の連携開業医を抱えており、その医師に仮想体験をしてもらうのが Dr.Connect と呼ばれるシステムである。
図 24 Dr.Connect
クリーブランドクリニックへ患者を送り出した連携開業医は、患者が病院に到着した時点 から患者に発生する全ての情報を知ることができる。連携開業医がこのサービスに登録す れば、その患者が病院の受付に来たときに、受付では画面にポップアップで、「この患者 は Dr.Connect による照会で来た患者である、患者に連携開業医に情報を送ってもいいか 尋ねること」と出るようになっている。患者が同意すれば、電子メールがすぐに連携開業 医へ送られ、90 日間は患者に関する情報を閲覧することができるということが伝えられ、連携開業医がユーザネームとパスワードを登録すれば、患者に関する全ての情報を閲覧す ることができる。連携開業医が見ているのは、クリーブランドクリニックの電子カルテ
（EMR）そのものをある制限の下に見ているだけである。連携開業医はクリーブランドク リニックの医師が書いたプログレスノートを読み、どんな薬が使われ、どのようなオーダ ーが出され、検査結果がどうであったか、ということをリアルタイムで見ることができる。連携開業医はレターやファックスや電子メールを待つ必要がない、すべてをオンラインで 見ることができる。
クリーブランドクリニックに雇用されていなくて、このサービスを利用している連携開業医は約 2,200 人いる。その中の 1,600 人はオハイオ州にいるが、急速に伸びているのはオハイオ州以外の地域である。
図 25 Dr.Connect の広がり
Dr.Connect の費用はタダである、何故なら単にブラウザを使っているだけだから。ブラウザは時間外にプロセスを改善してくれるので役に立つし、クリーブランドクリニックの医師による熟練した医療を本当に必要としている患者を広げてくれる。まさに Win-Winの関係である。さらに医師を医療行為のループの中に保持してくれるので、患者が自分の病院に戻って来たときには、最初に「どうしましたか？」と質問すればいいほど熟知するようになる。
c) MyPractice・Community
図 26 MyPractice・Community の広がり
MyPractice・Community は地域の病院でありながら、クリーブランドクリニックに雇用されていない医師に対して、クリーブランドクリニックの医師と同じ活動を提供するものである。月々の費用を払えば、地域の病院の医師のオフィスにはコンピュータとプリンタが届けられ、まず、クリーブランドクリニックと同じ電子カルテが導入される。医師は情報技術に詳しくなくてもよく、クリーブランドクリニック側が全てを行う。そして、トレーニングを行い、スキルを身に付けさせ、同じデータセンタが使えるようにサポートする。患者がクリーブランドクリニックのどこかの検査機関を利用した場合は、すぐにその結果を医師は見ることができる。地域の病院がもしディクテーションを利用しているのであれば、クリーブランドクリニックは病院で使用している高度なディクテーションモデルを地域の病院に提供する。そうすれば、コミュニティ病院の医師はクリーブランドクリニックで使用しているものと同じツールとその能力を手に入れることができる。月々の費用を払いさえすれば、全て同じことができるようになる。
クリーブランドクリニックではこのシステムをサードパーティに販売し同様のことをやってもらおうと考えている。そうすればクリーブランドクリニックを利用するしないにかかわらず、電子カルテの中で情報を得ることが可能になる。電子カルテの次のターゲットは小売薬局であり、電子的に書かれた処方箋が薬局に届けられることになる。電子カルテは
単一のデータベースであり、どのデータがどこから来たものであるか区別することが可能である。医師にはどこから来たデータなのかが分かるようになっている。
現在 200 人足らずの医師がこのサービスを利用しており、これらの医師のオフィスでは 4
～5 人のスタッフがサポートに当たっている。MyPractice・Community サービスの費用は医者ひとり当たり月 600 ドルであり、この中には医者のスタッフの費用も含まれている。
図 27 eResearch
eResearch の中核を成すのは単一のデータベースであり、クリーブランドクリニックではこのデータを集め、分析し、新しい知識を創り出すようにしている。クリーブランドクリニックではすでに研究を支援するプロセスが開始されており、実際に臨床試験を支えている。約 150 の臨床試験が同時に行われている。
研究を行うため、NIH（National Institutes of Health、アメリカ国立衛生研究所）や大手製薬会社から頻繁にスポンサー提供を受けている。このような研究はあるプロトコルの下に始められ、そして試験を行うかどうかが決められる。試験を行う場合、実際に患者を募集することは、特に製薬会社にとって非常に多くの費用がかかる。そのため、クリーブランドクリニックではフィージビリティ分析と呼ばれるサービスを提供している。 これは、依頼側から出されたプロトコルをクリーブランドクリニックのデータベースを使ってシミュレーションするものである。製薬会社が探している対象群を集め、基準に合わないものは除外することができる。その結果、製薬会社がその研究に必要としている患者の見込み数を告げることができる。現在、Merck、Astra-Zeneca、Eli Lilly などの製薬会社にこのようなサービスを行っている。フィージビリティ分析毎にお金が支払われ、これはクリーブランドクリニックの収入源にもなっている。フィージビリティ分析においてクリーブランドクリニックが提出するものは報告書だけであり、実際のデータは、患者の名前も患者を特定できるデータも、一切出さない。
報告書を見て臨床試験を実施することに決めた場合は、次のステップとして、クリーブランドへ来て 2 つの契約書にサインすることになる。ひとつめは、医療調査官との契約であり、ふたつめは、CIO との契約である。研究に関しては循環器内科医が第一次調査官を務める。CIO と契約するのは、それが電子的な試験サービスであり、対象となる患者の電子募集という部分と電子的なデータキャプチャや治験という部分があるためである。患者を集める場合は、まず全てのルールをシステムに書き込み、患者がどこに来てもその基準が分かるようになっていて、医師の画面に「この患者は資格がある」というポップアップが出る。医師がこの患者に試験に参加する意思があるかどうかを確認し、同意すればその時点で治験コーディネータが呼ばれることになる。医師と一緒のときに同意を得るというのが、すんなり対象の患者を集める最もいい時期であり、医師抜きで患者が個別にサインすることはまずない。
開始して 3 年になるが、記録によると、従来のやり方である試験のために掲示板で 800 人募集しても、100 人を集めるのに 18 か月もかかっている。同じ試験の募集をこの電子募集に切り替えたところ、4 か月で 100 人が集まった。この第一の理由は、患者が医師の目の前で契約したことであり、第二の理由は、募集に関わる医師の数が多いことである。医師の数が増えたのは、医師はxxxを知らなくても、誰でも参加でき、しかもコンピュータがその患者は資格があるのかないのかを教えてくれるためである。
現在取り組んでいるのは、電子的なデータキャプチャである。患者を募集し、データキャプチャのための FDA （Food and Drug Administration、食品医薬品局）フォーマットを作成している。FDA フォーマットで集められたデータは、最終的には製薬会社へ出され、そこでまとめられて FDA へ送られる。
e) MyChart
MyChart は個人健康記録（personal health record）であり、同じツールを使って病院と患者を繋ぎサービスを提供するものである。同じツールを患者から見て役に立つように、そして使いやすいようにしたものである。
MyChart で行っている患者サービスは以下の通りである。
図 28 MyChart サービス
View medical information （医療情報の閲覧）検体検査結果、放射線検査結果、など
View health reminders （ヘルスリマインダーの閲覧）医師が閲覧するものと同じものを閲覧できる
View schedule （スケジュールの閲覧） Appointment request （診療予約依頼） Prescription renewal request （処方箋更新依頼）
依頼を医師が見て、更新された処方箋を地方の薬局へ手配する
図 29 MyChart ログイン画面
患者はユーザネームとパスワードを登録し、それを使ってこのシステムに入る。このシステムが持つインテリジェントな機能のひとつは、まず病院から患者へ情報が伝えられることである。
図 30 患者へのメッセージ
例えば、予防的なケアについてレビューする必要がある、というような情報などであり、患者はまずこれを読む。メッセージは医師から来ることもあり、それは「新しい検査結果が出ていますよ」という内容が多い。
図 31 検査結果通知の例
患者はこのメッセージを受けて自分の検査結果を見に行く、勿論この検査結果は医師も見ている。
図 32 検査結果の例 1
図 33 検査結果の例 2
もうひとつのインテリジェントな機能は、患者にできるだけ知識を持ってもらうことである。検査結果は患者に分かりやすい情報にリンクされており、その情報のいくつかは病院やヘルスインフォメーションセンタから送られている。この患者に分かりやすい情報は、クリーブランドクリニックグループの患者に対して使われるだけではなく、WebMD や健康情報を扱う多くの販売業者に販売することも目的にしている。リンクボタンを押せば、検査はどういうものであるのか、それはどういう病気と関連しているのか、正常と異常がどういう意味を持つのか、などを患者に分かりやすい言葉で説明する画面にリンクする。
eCleveland Clinic の目標は、患者の病気や体調に関して、患者をできるだけうまく教育し続けることである。患者の立場に立った予防情報というものがあり、これは例えば「あなたは肺炎球菌ワクチンをこの日に受けました、しかし、あなたは糖尿病なのでヘモグロビン A1C の検査を行う必要があった。もう期限は過ぎているが、あなたのためにはやるべき時期である。」というようなものである。
図 34 予防情報の例
患者はこのシステムに入ることにより、これまでやることがなかったようなことにトライするようになった。例えば、患者が期限が過ぎているマンモグラムのリクエストを出す場合、患者は病院に電話をすることなくスケジュール画面からオンラインで行うことができる。病院側ではそのリクエストを受けて、患者がいつどこに行ってマンモグラムを受けたらいいか、というメッセージを返す。
投薬は個人健康記録（PHR）の重要な部分のひとつであり、そのサービスは自動的に行われるようになっている。医師が処方箋を書けば、それは自動的に患者の投薬リストに表示される。そして、患者がその処方箋を更新したい場合は、オンラインで更新をリクエストすることができる。
図 35 処方箋更新依頼の例
米国では、殆どの州が処方箋の有効期限を 12 か月と定めており、期限が近づくと医師は患者に対し新しい処方箋を書かなければならないようになっている。患者は医師にどの薬を更新しなければならないのか、どこの薬局に処方箋を送ってほしいのか、をリクエストする。医師は一日中診察していても、診察の合間に、自分のインバスケットでリクエストを見て、画面に表示されている処方箋を選んで更新のところに埋め込めんで更新し、それを送ればいいだけなので、診察の妨げになることはない。米国の全ての大手小売薬局でこのようなやり方が行われている。
MyChart に登録している人は約 16 万人でその 3 分の 2 が実際に使用している、毎月約 3,500 人が新たに登録している。MyChart の ID はオンラインで簡単に取得することができる。従って、最初だけ電話で予約を入れるが、次からは文字通りオンラインで予約を取ることができる。患者が最初に病院へ来た時は、MyChart の ID を持ってそれを見せることになるが、これはクリーブランドクリニックの総合的な ID であり、勿論 MyChart の ID としても使える。MyChart への登録は、患者が医者と一緒にクリーブランドクリニックへ来たときに、受付でも行うことができる。勿論オンラインでも登録できるので、そのためにわざわざクリーブランドクリニックまで来なくてもいい。患者が自分の都合に合わせて選べばいい。登録方法については、MyChart を閲覧すればそこに書いてある。
クリーブランドクリニックの ID システムは、マスター番号と関連するマスター索引を持っていて、それで全てを管理している。仮に患者が自分の ID に自宅の電話番号を使っていたとしても、クリーブランドクリニックのコンピュータではマスター番号が全てに同期して動いている。従って、例えば患者がクリーブランドの患者でもあり、フロリダの患者でもある場合、患者の情報はひとつの電子カルテに記録されるようになっている。マスター番号は非常に精巧に作られているので、その番号を知ることはできない。患者はフロリダの電話番号を使うことができるが、コンピュータ上ではその番号がどのマスター番号にマップされるかわかっており、全てがマスター番号に詰め込まれ、従って、患者は全てのデータを閲覧することができる。
f) MyConsult
図 36 米国の一般的な診断・治療プロセス
米国の一般的な診断・治療プロセスは、まず症候が出たら、プライマリ・ダイアグノーシスを受けた後に治療計画が決められる。この時点で、セカンドオピニオンを希望するかどうかが患者に打診され、患者が承諾すればセカンドオピニオンに相談することになり、もし患者が承諾しなければ、別の治療計画を検討することになっている。
クリーブランドクリニックのセカンドオピニオンサービスは、世界中のどの地域の患者にも対応している。どこかの場所で医者に診てもらい、化学療法を勧められたり、手術などを受けて、うまくいっていた患者が突然ある症候を発することはよくあることで、そういう患者の 80％がセカンドオピニオン先を探すことになる。このような患者がクリーブランドクリニックに電話をかけ、ファックスを送り、電子メールを送り、サービスを受けようとしていることが分かったので、そのプロセスを電子化してオンラインでサービスすることにした。患者はクリーブランドクリニックの患者でなくてもウェブ上でセカンドオピニオンサービスを受けることができる。
このシステムには 7 ステップのプロセスがある。
図 37 セカンドオピニオンサービスの 7 ステップ
第 1 ステップ 依頼者情報、依頼者の基本的な登録情報第 2 ステップ 患者情報、患者の基本的な登録情報
第 3 ステップ 診断または問題、患者の一次診断情報
第 4 ステップ 支払手続き、依頼者のクレジットカード情報
第 5 ステップ 診療経過、患者の診断や診療経過において特記すべき事項過去の症候や受けた治療、投薬など
第 6 ステップ チェックリスト
第 7 ステップ レビューと最終承認、記入した情報を確認し承認する
最も重要なポイントは、第 3 ステップの診断であり、患者は一次診断情報（プライマリ・ ダイアグノーシス）を持っていたらそれを記入しなければならない。クリーブランドクリ ニックではプライマリ・ダイアグノーシスは行わず、6,000 項目の中の約 250 項目につい てセカンダリ・ダイアグノーシスを行う。料金はサービス内容により決められており、ク レジットカードで決済される。送られてきた情報については看護師がその内容が完全であ ることを確認し、どのような医師がその患者に必要か確認し、医師をアサインする。患者 を診察していない医師が選ばれ、その医師はセカンドオピニオンを引き受けなければなら ない。医師によるxxxxx・xxxxxxxxが完了すると、患者へメッセージが送ら れ、患者は医師によるxxxxx・xxxxxxxxを見ることができる。メッセージの おおよそ 36～48 時間後に、xxxxx・xxxxxxxxに関する注釈が付け加えられ、何故そのような勧告を出したかが示される。患者は、何故この医師が選ばれたのかを知り、その医師の専門性やその医師がこの領域でエキスパートである理由などを確かめることが できる。二度目のメッセージが送られてからおおよそ 48 時間後に病院は患者へ電話を入 れる。このタイミングは、患者が知識を得て、疑問に思っていることを質問するのに最適 な時期だからである。
MyConsult のシステムは、米国内に限らず、世界 60 か国で現在運営されている。
図 38 MyConsult を運営している国
このシステムを運営する上で最もやっかいなのが米国である。何故なら、米国の約 17 の州では、医師は患者が住む州の免許を持っていないと、患者に対して直接このようなセカンダリ・ダイアグノーシスをすることができないからである。従って、17 の州でこのようなことをやろうとすると、それぞれの医師は 17 もの医師免許を取得しなければならない。17 の州はほとんどが海岸線にある大きな州であり、全米の人口の約半数が海岸線から約 1 時間半以内に住んでいる。このような州では、実際に医師免許を取得するようにしている。それ以外の中央部の州では州をまたぐセカンダリ・ダイアグノーシスを行うことは可能であるが、患者は同じ州に住む医師を見つけ、その医師に照会をしてもらわなければならないようになっている。州の医師からの照会は、医師から医師への照会であり、州の医師が免許を持っていれば、クリーブランドクリニックの医師がその州の免許を持つ必要はない。こういう州では、医師と医師による相談のみを行っている。
g) VirtualVisit
このシステムは、クリーブランドの医師に診てもらう必要があるが、クリーブランドまで来ない患者のためのものである。
図 39 VirtualVisit の様子
VirtualVisit 装置は、現在は、フロリダのクリーブランドクリニックとは関係ない施設 の中に設置されている。この施設には、いわゆる eClevelandClinic の小さな部屋があり、この部屋の中に、テーブルとデジタル機器一式と、スクリーンとカメラが置いてある。こ
こにはアシスタントはいるが、医師はいない。患者はxxxxxを通してクリーブランド のメインキャンパスにいる医師と面会する。医師は患者を見て話をし、患者の話を聞く、 そしてアシスタントの手助けでこの患者を遠隔診察する。部屋には電子聴診器とオトスコ ープと検眼鏡が置いてある。大がかりな腹部の検査を除き、基本的に何でもできる。医師 側には 4 つのスクリーンがあり、もし患者が書類を持っていたら、それを伝送装置を使っ て見ることができる。こうすることでプライマリ・ダイアグノーシスを行うことができる。 VirtualVisit はあくまでもプライマリ・ダイアグノーシスに限られる。このプライマ リ・ダイアグノーシスの診断情報は MyPractice の電子カルテに取り込まれる。
このようなサービスを希望する施設に対してクリーブランドクリニックはこのプログラムを提供する。装置は高価なのでクリーブランドクリニックからは提供されない。希望する施設は自前で購入しなければならない。この遠隔診察においては、医師はこのオハイオ州の免許を持ってさえいれば、患者がいる州の免許を持っている必要はない。医療は、麻薬中毒（これは連邦法）を除き各州法で決められており、この遠隔診察は州法上は合法である。そして、一旦患者を診察すれば、その患者がどこの州にいようと処方箋を書くことができる。
h) MyMonitoring
これは同じシステムを使った患者向けサービスのひとつで、これにより退院後は静養地や自宅に居ながらクリーブランドクリニックにケアしてもらうことができる。患者は静養地や自宅から自分の日常の経過情報を病院に報告する、それを受けて病院の医師よりどういう具合にケアをすればいいか連絡が行くようになっている。
【背景】
質のいい医療を安く提供できれば、それは大変価値のあることである。クリーブランドへ飛行機で来て最も高度な医療を受けるのも、それだけの費用をかける効果はある。費用対効果を年度内に出すことはさらに重要なことであり、米国の保険会社などは 1 年どころか四半期毎の財務成果をウォールストリートへ来て説明しなければならないので大変重要だと考えており、彼らは儲けがないものには全く興味を示さない、それは大きな問題でもある。
クリーブランドクリニックでは、クリーブランドという特殊な場所で、1 年間かけて、価 値のある医療をデモンストレーションするための仕掛けをつくってきた。予防というのも より良い取り組みではあるが、それには時間がかかり、クリーブランドクリニックが他と の違いを見せられるようになるには 5 年が必要である。最も高度な医療に関しては、いい モデルがある。それは、1 パーセントの人が 9 パーセントのお金を使っているということ である。彼らがうまく振舞えば、質のいい医療をもっと安価に手にすることができる。米 国の大統領選挙において、その結果を左右するもののひとつが医療である。控え目に見積 もっても、約 4500 万人が医療を受けていないことは疑う余地がない。そのような人たち は、病気になり、クリーブランドクリニックへ来る、そしてそこで面倒を見ることになる。 ED（勃起障害）になった人にはすぐに面倒を見なければならない義務がある。 従って、 4500 万の人たちをカバーするために、より多くのお金を使うことになるが、それでいい のだろうかという疑問がある。
クリーブランドクリニックでは、この問題を解決するために、まさに医療情報技術を効果 的に使う必要があるという考えに至った。そしてそれはクリーブランドクリニックだけが やるのではなく、国がやって、4500 万の人たちをカバーすべきであり、そうでなければ、使うお金はもっと増え、誰も幸せになれないだろう。クリーブランドクリニックでは、情 報を繋ぐことを自らやってきたが、国中の全ての医者のことを考慮し、そのリソースはク リーブランドだけに置くことはしてこなかった。米国には、約 80 万人の医師と約 5 千か
所の病院がある。クリーブランドクリニックは問題を解決するためにはパートナーが必要であったので、eCleveland Clinic のような取り組みを進めてきた。念願である相互運用性を達成させる見通しを考えると、誰にも邪魔されたくなかった。
患者がどのような情報交換を使うことを選択するか、はその患者自身が決めることである。クリーブランドクリニックとしては、あらゆる相互運用性を実現したいと考えている。国 レベルでは、連邦政府と一緒に相互運用性のモデルに取り組んでいるし、州レベルでは、 オハイオ州で RHIO の開発に取り組んでいる。そして、個人レベルとして、8 か月前
（2008 年 2 月）にグーグルとのプロジェクトを開始し、個人側の交換を使って情報交換を達成することを目指した。
【Google Health との連携の概要】
a) Google Health プロジェクトの立ち上げ
図 40 情報の取り込み
Google Health を使えば、米国の全ての医者や、病院、小売薬局、民間検査機関などの情報（健康状態、アレルギー、投薬、検査結果、など）を Google Health のウェブページに移すことができる。次に、患者は自分の情報を Google Health からクリーブランドク
リニックの電子カルテの中に移動させることができ、最終的にはそれをクリーブランドクリニックの医師が活用することになる。
図 41 医師による情報の活用
クリーブランドクリニックでは、グーグルとのプロジェクトの中でも特に情報を交換する部分に力を入れた。Google Health ではそれ以上のことができるが、クリーブランドクリニックはそこにしか興味がなかった。中味は何であれ、とにかく繋ぐということがクリーブランドクリニックの目標である。繋ぐことができれば、患者は情報を引き出して彼らの個人アカウントに収めることができる。クリーブランドクリニックが作ったモデルは、患者がエンパワーするモデルである。プライバシーの観点では、患者に情報の流れをコントロールすることを許せば、情報は患者が管理するので、医師はプライバシーについての配慮を無視してもいいことになる。患者以外の者がもし患者に関する情報を管理することになると、その人は山のような心配をしなくてはならなくなる。
現時点でクリーブランドクリニックが認めることができる唯一のことは、患者がエンパワーするモデルに限られる。Google Health を使っている患者がクリーブランドクリニックに来たときに患者にやってもらうことは、Google Health の情報をクリーブランドクリニックへ電子的に送ってもらうことである。こうすることがまさにクリーブランドクリニッ
クが求めているモデルであり、その情報を見る医師にとって大変役に立つことである。
2008 年 2 月に試行を開始し、45 日くらいで約 1,500 人の患者がこの試行への参加登録を 行った。クリーブランドクリニックでは、まず最初にユーザインターフェースを評価した。情報交換の速度がこういうものでは問題になるので、変換速度を最も注視した。グーグル 側のユーザインターフェースには少し修正が必要で、クリーブランドクリニック側は情報 提供のしかたの点で、もうひと工夫が必要であった。3～4 か月の試行を行い、5 月か 6 月 の初め頃にグーグルは全体としての製品化に至った。
国内の小売薬局、民間検査機関、その他の仲間を含めることで、付加価値サービスが実現し、2008 年末には 250 くらいのパートナーの参加が期待できる。当初はそのような規模は予測することができなかった。コンピュータビジネスということで考えると、毎日 1 億の人が利用するくらいの規模に相当すると思われる。これはそんなに驚くべき数字ではない。クリーブランドクリニックの目標は、決してクリーブランドクリニックに来ることのない患者がこうしてクリーブランドクリニックと実際に出会い始めることである。Google Health のアカウントに登録し、そこに情報を置き、病院に行く前に医師に見てもらうように管理し、実際に病院に行く前にプランを修正することができるようになる。これは病院側にとってもひとつの大きな前進である。これはグーグルだけに限定する話ではなく、他のプレイヤーにも期待している。マイクロソフトも既に対抗製品を出している。 また大手の電話会社が 2 社ほどこのビジネスに参画しようとしている。現在テネシー州では AT&T によって大きな試行が行われており、今のところひとつの州に限定しているが、将来は国内に展開するモデルを狙っている。
b) Google Health との連携の例
ある患者（仮に名前を Mr. Xxxxx とする）がアリゾナに住んでいて、心臓の具合が悪く、手術をしなければならない。クリーブランドクリニックに行ってセカンドオピニオンをx xしたかったが、アリゾナを離れられなかった、としよう。Mr. Xxxxx は MyConsult に 登録し、ウェブで情報をクリーブランドクリニックに送り、クリーブランドクリニックの 医師への相談が完了すると、セカンドオピニオンの意見として Mr. Xxxxx には手術が、 人工弁に交換するのではなく弁修復の手術が必要であると勧める。（注：クリーブランド
クリニックのモデルでは、Google Health の情報を MyConsult に送ることが出来る。この点はベスイスラエル病院と異なる）。
図 42 MyConsult による相談
弁修復手術ができる所はそんなに多くないが、Mr. Xxxxx は人工弁にしたくないため弁修復手術を行うことを選択し、この弁修復手術は技術的にかなり難しいが、クリーブランドクリニックでこの手術をやることになり、実際に手術を行う。クリーブランドクリニックでは手術を行う前に Mr. Xxxxx に次のように言う、「クリーブランドクリニックに来る前に、ふたつやってほしい。ひとつは、もしあなたが何か情報を持っているのであれば、 Google Health のアカウントを取って、その情報を集め、そしてその情報を我々のところへ送ってほしい」。
図 43 Google Health への情報の収集
Google Health のアカウントを取り、情報を管理し、情報をクリーブランドクリニックへ届けるのは患者である Mr. Xxxxx であり、クリーブランドクリニックが何かを認可するわけではないし、そこにはどんなプライバシーの議論も必要ない。Mr. Xxxxx が単に決めてクリーブランドクリニックに情報を送って電子カルテに格納するだけである。
図 44 クリーブランドクリニックへの情報の移動
そして、Mr. Xxxxx がクリーブランドクリニックへ実際にやってきたときには、彼の情報はクリーブランドクリニックの医師が活用できるようになっている。
図 45 電子カルテに取り込まれる情報
クリーブランドクリニックは Mr. Xxxxx に言う。「もうひとつは、あなたが出発する前に、MyConsult を通して、あなたがかかっている医者を Dr.Connect に登録してほしい」と。何故なら、Mr. Xxxxx を長期間面倒見るのはその医者になるからである。Mr. Xxxxxが実際にクリーブランドクリニックへ来たら、Mr. Xxxxx へ行われる医療の情報は電子カルテの中に入る。Mr. Xxxxx がかかっていた医者は Dr.Connect に登録されているので、クリーブランドで何が起こっているのかは、毎日、リアルタイムで知ることができる。
図 46 Dr.Connect による情報交換
Mr. Xxxxx の医者はその患者への仮想のパートナーとなり、何かミスがあると感じたとき は、その医者はクリーブランドの医師に話をすることができる。Mr. Xxxxx はクリーブラ ンドで手術を受け、精巧なペースメーカを体内に埋め込まれ、静養のため自宅へは戻らず フロリダへ移動する。Mr. Xxxxx にはペースメーカを埋め込んだ医者によるフォローアッ プが必要であり、そのためにはインターネットに接続されたコンピュータが必要になる。 どこかのホテルの部屋で MyMonitoring を使って、例えばデジタル血圧計のデータなどが、クリーブランドクリニックの医師にモニターされることになる。一般的に 3 日間インター ネットに接続し、情報が伝達される。
図 47 MyMonitoring による術後のフォロー
非常に限定されているが、現在フロリダには VertualVisit サービス用の部屋を備えた施設を持っており、もし患者がクリーブランドへ戻るほどではないが医師と面会する必要がある場合は、この施設に行き、予約しておいた医師と面会することができる。
図 48 VirtualVisit を使った面会
フロリダでの静養が終わり Mr. Xxxxx がxxxxの自宅に戻ったら、次に Mr. Xxxxx の医者が Mr. Xxxxx をケアしていくために、 Dr.Connect を利用して必要な情報をクリーブランドクリニックから入手することになる。このようにして、自宅へ戻った後も、 MyMonitoring、MyChart、Dr.Connect を使って Mr. Xxxxx はクリーブランドクリニックの医師による術後のフォローアップケアサービスを受けることができる。
図 49 自宅でのフォローアップサービス
Mr. Xxxxx はクリーブランドクリニックの MyPractice にある記録を今度は Google Health へ移動させることもでき、この記録は Mr. Xxxxx が将来どこかの病院で医療を受けるような場合に使うことができる。
図 50 医療情報の活用
c) Google Health との連携の有効性
クリーブランドクリニックの医療理念は、患者中心の医療であり、その考えで作り上げた Google Health との連携モデルは、今後米国内で広く使われて行くであろう。何故なら、これからの 20 年間で退職する人の数は、これまでになかった規模であり、現在 35～55 才の人は 55～75 才になり、そのような人たちに現在クリーブランドクリニックが行っているような医療を提供できる病院も医師も不足することになるからである。この場合、もっと有効なやり方が必要になる。病院施設を建設するにはかなりお金がかかる。大統領選挙の結果の如何にかかわらず、医療サービスの増加に対する支出分を捻出しなければならない。選挙での争点は、医療サービスに対して国民が支払うか否かという単純なものになっていて、民主党は保険適用範囲を広げるべきという考え、共和党は広範囲の階層の国民に税的優遇措置を提供するという考えである。どちらであっても歳入は減ることになり、お金は不足する。従って、病院が行う医療にかけるお金を減らさなければいけない。（注：患者の絶対数が増えるので、一人当たりの医療費を減らすべきという意味。トータルな医療サービスはむしろ増えるかも知れない。）
そこで考えなければならないことは、慢性病の管理である。8 つの慢性病（心臓疾患、糖尿病、喘息、肥満、など）で、たった 6 つから 8 つの診断に、おおよそ 7 割の医療費を使っている。これらの患者のかなりの数が州をまたいで移動しながら何らかの理由で入退院を繰り返している。病院への入退院の繰り返しが増えれば、それにかかる費用も増える。最初にやるべき最重要の取り組みは、病院に入退院を繰り返すことを予防するためのプログラムを構築することである。入退院を減らせれば、多額のお金が節約できる。
d) 医療コスト低減の考え方
これまでのやり方だと、例えばよくある病気の糖尿病と高血圧の場合、病院は 3 から 4 か月おきに患者を診察し、患者への投薬を調節するだけであり、このやり方は全く意味がない。何が患者に起こっているのかというちょっとした情報をもっとたくさん取って、より細かく調節することがより意味がある。医師がもっと頻繁に患者と相互に関わり合えるように、ただそのシステム利用に法外な費用がかからないように修正をしながら技術を応用すれば、理論的にはコストを引き下げることができる。この技術を使えば、消費者に焦点を置いたよりよいサービスが提供できるだけでなく、全ての市民をカバーできるという利益を生み出すこともできる。
図 51 医療コスト低減の考え方
e) クリーブランドクリニックの eHealth Service が消費者にもたらすもの
医療にたくさんのお金をかけることはできないという事実から逃れることはできない。今や、医療は医療提供者側が動かすモデルから医療を受ける側が動かすモデルに変える過渡期にきている。そのためには、患者の医療に患者自身が積極的に参加することを考え始めるように患者をエンパワーし、それができるツールを与えなければならない。患者が必要とするときに、必要とする場所で、必要とするサービスを提供することにより、実際に患者の希望を満たすことができると確信している。
f) Google Health 以外との連携
クリーブランドクリニックが現在連携している接続先は、Google Health 以外に、連邦政府の機関である NHIN（National Health Information Network、全米医療情報ネットワーク）だけである。将来はスイッチ（情報のハブ）となり得るところであればどことでも、例えば AT&T のような電話会社やマイクロソフトとも連携する考えであり、マイクロソフトとはすでに話を進めている。
g) Google Health とのデータ交換について
Google Health との連携はボストンのベスイスラエル病院でも行われており、そこでは患 者がベスイスラエル病院にある自分の医療データを自由に Google Health にアップロー ドできるが、逆に Google Health からはダウンロードはできないようになっている。一方、クリーブランドクリニックでは、Google Health と双方向でデータ交換を行っている。患 者は、MyChart から情報を Google Health へ送ることができるし、他の情報も Google Health へ送り、Google Health に情報を集めたうえで、全ての情報を、クリーブランドク リニックの電子カルテの中に持ち込むことができる。ただし、これはすべて患者がコント ロールすることである。
クリーブランドクリニックでは、民間検査機関のデータや薬局のデータなどは、情報源によってはデータベースに入れないこともある。例えば、ある患者が血液検査を行って、その結果をその患者の Google Health のアカウントへ入れて、その後、この患者はある薬草のサプリを摂取したことが重要なことだと思って、同じように Google Health のアカ
ウントへ入れたとする。民間検査機関✰データは信頼できるも✰な✰でそ✰情報は受け入れられるが、薬草✰サプリについてはそうはいかない。そ✰情報は電子カルテ✰中に報告されるが一旦別✰ところに置かれて、医師によるレビューが行われ、医師が合意してデータベースに入れる処理をすれば、データベースになる。それはある意味厄介なノートであり、フィルタリングが必要な情報については、そ✰ままデータベースに入れることはしない。患者が病院へ来てたくさん✰ことを話したとしても、そ✰全てをコンピュータに入れる訳ではない。
患者が引っ越しをする場合、クリーブランドクリニックにあるすべて✰情報は、そ✰患者
✰ Google Health ✰アカウントへ移され、患者は引っ越し先で Google Health に接続できる新しい医者を探すことになる。こ✰ように Google Health は一種✰スイッチングであり、可搬できる部品✰ようなも✰である。
Google Health はわずかなコストで患者に莫大な付加価値を提供するサービスであり、それはグーグル✰基本モデルに合致している。例えば、患者が Google Health にログインしているときに何か物が必要だと思えば、すぐにグーグル✰サイトへ行き検索できる。ただ、Google Health はグーグルから独立しており、Google Health には広告が一切ない。プライバシー✰心配がある✰で、Google Health ✰情報は検索に✲うことができない。クリーブランドクリニックが Google Health へ移すデータは、今✰ところデータ✰構造とテキストデータ✰みであるが、イメージデータについては現在議論している。イメージデータは互換性✰問題があり、例えば CD に入ったデータ✰場合、70％は読み出しが出来るが、30％は読めない✰が実状であり、Google Health で✲うということになると早く標準化をしなければならない。
1.2.5 規格について（何故 HL7 でない✰か？）
グーグルは CCR （ Continuity of Care Record ） を✲用し、マイクロソフトは CCD
（ Continuity of Care Document ： CCR を CDA 化したも✰） を✲用、連邦政府は CDA
（Clinical Document Architecture） を✲用している。図式としては CCR 対 HL7 ではな
く、CCR 対 CCD、CCR 対 CDA である。CCR と CCD ✰差は取るに足らないも✰であり、誰がどちらを選ぼうがクリーブランドクリニックは気にしない。グーグル とマイクロソフト
は CCR ライクな方に決め、連邦政府は CCD ライクな方に決めたというだけである。規格が 3 つもあるということは米国にとって大変な害である。連邦政府はシステムを管理する
ことはせず、システムにかかるコストが増えないように統制するだけである。もし 3 つとも対応するということになると、すべて✰ユーザインターフェースに対応しなければならないため、クリーブランドクリニックにかかるコストは指数関数的に増大する。クリーブランドクリニックはこれら 3 つに対応する能力は持っているが、ここは連邦政府✰力を借りなければならないと考えている。
クリーブランドクリニックは現在は CCR をサポートしているが、費用はかかってもすぐに CCD へ切り替える予定である。何故なら、長期間 3 つ✰規格に対応し続けるコストに比べると、そ✰費用は大したも✰ではないから。これは大変な挑戦である。CIO ✰ Dr. Xxxxxx は AHIC（American Healthcare Information Community、全米医療情報コミュニティ）✰一員に任命され、そこで個人向け✰医療とサービスを検討するグループ✰幹事✰職につくことになった。こ✰会合は公✰前でやらなければならないし、グーグル やマイクロソフトも連邦政府と並んで同じテーブルに着くようにし、何故彼らが別✰規格を✲おうと考えている✰か、説明させなければならない、と Dr. Xxxxxx は考えている。
1.3 ベスイスラエル病院（Xxxx Xxxxxx Deaconess Medical Center）
1.3.1 視察概要
視察日：2008 年 10 月 22 日（水）
視察先：マサチューセッツ州ボストン ベスイスラエル病院情報部門オフィス会議相手：
Xxxx X. Xxxxxxx, MD：Chief Information Officer Xxxxx Xxxx, MD：Manager, Information Systems Xxxxxxxx Xxxxxx：Analyst, Information Systems
図 52 Dr. Xxxxxxx と視察メンバー
図 53 会議の様子 1
図 54 会議の様子 2
1.3.2 ベスイスラエル病院
ベスイスラエル病院は、マサチューセッツ州ボストンにある、全米で屈指の病院のひとつである。1896 年に設立された「New England Deaconess Medical Center」と 1916 年に設立された「Beth Israel Hospital」が、1996 年に合併し「Beth Israel Deaconess Medical Center」としてスタートした。現在、前者は「West Campus」と呼ばれ、後者は「East
Campus」と呼ばれている。Harvard medical School の大学附属病院であり、医療事業以外に研究や教育にも力を入れている。ベスイスラエル病院の年間外来患者数は約 75 万人である。
1.3.3 PatientSite
【開発の経緯】
米国の医療機関にとって、患者をいかに確保するか、がxxの課題になっていて、ベスイスラエル病院では 2001 年に、患者はどのような医師や病院を選ぶのか、についてボストンで調査を行った。その結果、調査した患者の 19％が、電子的なツールを使って患者へサービスをしてくれる医師や病院、すなわち、患者とセキュアーな電子メールの交換をしたり、EHR （Electric Health Record、電子カルテ）をシェアしてくれるような医師や病院を選ぶことが分かった。
従って、ベスイスラエル病院がウェブを使った魅力的な医療情報サービスを患者に提供できるようになれば、患者は病院を替えてでもベスイスラエルに来てくれるであろうと考えた。その具体的なサービスが PatientSite であり、7 年前にオンライン医療情報サービスとしてスタートした。PatientSite の初期開発コストは約 25 万ドルであった。
【概要】
a) PatientSite への登録
患者はまずウェブ上の PatientSite の登録画面で自分の名前や性別、生年月日などの個人情報を書き込み、現在かかっている医師の名前をリストの中から選び、ベスイスラエル病院へ送る。これを受けてベスイスラエル病院側では、患者により選ばれた担当医師が患者に対してユーザネームとパスワードを発行する。患者は医師からもらったユーザネームとパスワードを使って PatientSite へログインし、自分の医療記録にアクセスすることになるが、そこで使われている名前が、自分の本当の名前ではなく別の平凡な名前になっていることもある。これは患者と医師以外の第三者による患者の特定を防止するための措置であり、これが医師の重荷になっているという問題はあるが、ベスイスラエル病院側での患者のミスマッチは全く起こらず、正しく管理されている。
米国には連邦政府が発行する医療用 ID というものはなく、PatientSite では上記のようなユニークな方法を採用している。一方で、社会保障番号のような統一されたもので医療情報を管理すべきだ、という意見や、セキュリティ度が高い本人認証方法、例えばユーザ
ネームとパスワードにもう1 要素加える方法を採用しようという動きが連邦政府や州政府の中にあるが、ベスイスラエル病院ではふたつの理由でそのような意見には賛成していない。ひとつは、現在の PatientSite のやり方でセキュリティ問題は全く発生していないこと。もうひとつは、今後はグーグルやマイクロソフトなどとの医療情報交換が進むが、グーグルもマイクロソフトも患者の証明書を管理してくれないからである。
b) PatientSite のサービス内容
PatientSite では患者がやりたいことは何でも簡単にできるようになっている。
患者がログインすると、まず担当医師からのメッセージがそこに表示されている。もし PatientSite がメインテナンス中であれば、その旨のサポートメッセージが表示されるようになっている。
患者は PatientSite から医師に対してセキュアーな電子メッセージを送ることができる。その内容は、以前は電話やファックスで問い合わせていたようなことが大半であり、最初 はメッセージが多すぎて医師に負担がかかるのではないかと心配していたが、そのような ことはなく、逆に、医師は患者へコールバックし連絡を取ろうとする必要がなく、また、患者からのメッセージは医師と一緒に仕事をしている看護師や事務員にも転送すること ができるので、病院内でのワークフローが以前よりも改善されたという効果が出ている。予約は、患者が医師の予定表を見ながら、3 週間先まで、15 分刻みで予約を行うことがで きる。医師のスタッフが、その予約が適当であるかどうかを確認した上で予約を確定する。検査結果については、患者は基本的に医師と同時に閲覧することができる。しかし、異常 値が出ているときに、いきなり患者に通知すると患者が不安になることもあるので、特定 の項目については、まず医師が確認した上で患者に通知するようにしている。例えば、が ん診断では、がんが見つかった場合は、まず医師が患者と直接話し合うようにしている。また、病理学と細胞学に関する検査結果については患者の閲覧を 2 週間遅らせ、CT や MRI などの画像診断については 4 日遅らせるようにしている。
処方箋の更新もオンラインで行えるようになっていて、患者は必要な投薬内容を選び、投薬更新をして欲しい医師を選ぶだけで良い。投薬記録が残っているので、投薬内容はリストの中から選んで埋めることができる。そして、どこの薬局で処方してほしいかを書き込んでクリックすれば、それは医師の元に届き、それから指定された薬局へ送られることになる。（注：日本の処方箋とは異なり、米国では処方の更新が可能）
患者は、処方箋以外の投薬記録や、民間検査機関での検査結果や、自宅で測定した何らかのデータなどを PatientSite に追加（入力）することができる。従って、PatientSite には、病院側から来るものと、患者が自ら追加するものの両方の医療記録が保管されることになる。
c) PatientSite の利用状況
現在、毎月 4 万人の患者が PatientSite を利用している。利用している患者は大きく 2種類に分けられる。ひとつは、鬱血性心不全や糖尿病、多発性硬化症、慢性閉塞性肺疾患などの慢性病の患者であり、例えば、薬を変える必要があるとか症候が変化したというように、患者は医師と詳細を相談するようになり、そういう患者はその医師の長期に亘るユーザであり続けることになる。もうひとつは、急病の患者であり、手術が必要であったり、伝染病であったり、そういう患者にも PatientSite に登録してもらうことになるが、2～ 3 か月間使った後に快復したら使わなくなることが多い。
PatientSite のユーザは常に入れ替わっていることになるが、アクティブなユーザは月 4万人であり、毎月少しずつ増えている。ユーザの年齢は若い人が多く、65 才以上の患者の割合は 10％である。デジタルデバイドの影響がここにも出ている。ベスイスラエル病院側では、300 人の医師と 350 人のスタッフが PatientSite を使っている。
d) PatientSite の運営実態
ベスイスラエル病院では PatientSite 運営のための予算を特別に持っている訳ではない。現在患者の登録数が増え、医師の登録数も増えているが、そのための特別な予算はなく、例えば、患者のサポートはひとりでやっており、また、システムのアップデートを維持す るプログラマもひとりかふたりで、それほど費用をかけないで行っている。ベスイスラエ ル病院の情報部門は、ボストン市内の病院から離れた場所にあり、簡素な体制で運営され ている。監視室とxxxxxxはそれぞれ 1 名の要員が現場にいるだけである。
図 55 監視室
ベスイスラエル病院の全情報システムを監視している
図 56 サーバルーム
ここの一角に PatientSite のサーバも置いてある
ベスイスラエル病院は Google Health や Microsoft HealthVault と連携することによって、患者をベスイスラエル病院に引き付け、より多くの患者を保有できればいいと考えており、グーグルやマイクロソフトなどの企業と連携することにより何らかの収入、例えば広告収入のようなものをもらおうという考えは持っていない。現在は Google Health を通
じて薬局や民間検査機関などとの連携もできるようになってきているので、現在の運営を続ける中で患者を増やせていけるという見通しを持っている。
1.3.4 EHR の PatientSite 以外への利用状況
a) IT 企業との連携
PatientSite の情報は、患者が希望すれば Google Health や Microsoft HealthVault へ転送することができる。Google Health とは 2008 年 2 月から、Microsoft HealthVault とは 2008 年 10 月から連携を開始した。
しかし、ベスイスラエル病院は Google Health や Microsoft HealthVault からは情報はもらわない。何故なら、患者が追加する情報、例えば投薬記録や注釈というものは必ずしも正確ではなく、これらの情報をベスイスラエル病院のEHR に追加してもいいものかどうか、医師が判断に迷うからである。
b) 保険請求への利用
米国の多くの人は、保険会社を信用していない。従って、ICD（International Statistical Classification of Diseases and Related Health Problem、国際疾病分類）コードの診断情報であれば保険会社と共有してもいいが、検査結果や投薬リストなどの詳細な医療情報までは共有したくないと思っている。従って、ベスイスラエル病院では詳細な医療情報を保険会社へ出すことはしていない。マサチューセッツ州では、病院と保険会社の CIO が集まり、医療の質や糖尿病などの慢性病をどう管理するかということについて話し合いを持った。そこでは、選ばれた民間検査機関のデータであれば、病院から保険会社へ情報を出してもいいであろうということになり、2009 年よりこれが開始される。
c) 公的統計等への利用
ベスイスラエル病院からは、毎日約 4,000 項目のデータが CDC（Centers For Disease Control、米国疾病予防管理センタ）へ送られ、このデータを元に伝染病や熱帯病などに関する公的な健康調査が行われている。4,000 項目の選定については、ベスイスラエル病院と CDC が相談して決定した。このデータは、ベスイスラエル病院内で自動的に作成される HL7/CCD（XML）形式で送られる。
マサチューセッツ州ではインフルエンザの発生状況を州内の病院と連携して調査している。ベスイスラエル病院からはインフルエンザ発生に関するデータ（年齢、診断、生死、
症候、症候については例えば咳が出るとか熱があるとかいう内容）を州保健局
（Department of Public Health）へ報告しており、州保健局はこのデータを元に、マサチューセッツ州内のインフルエンザ発生状況をまとめている。
図 57 インフルエンザ発生状況
さらに、ベスイスラエル病院は州政府と協力して、救急搬送患者に関する調査を行っていて、どういう症候の人が何人いたか、というようなことを追跡調査している。
ベスイスラエル病院は個人情報が漏れないために、個人のデータや個人を特定するデータは、州保健局にも米国疾病予防管理センタにも一切出していない。
1.3.5 Google Health との連携
【経緯】
ベスイスラエル病院の CIO である Dr. Xxxxxxx（Xxxx X. Xxxxxxx）は、最初にグーグルが PHR（Personal Health Record、個人健康記録）の提供を始めると聞いたときに、自ら作業に加わった。その理由は、莫大なリソースを持っているグーグルが、プライバシーやセキュリティ保護の保証をどのようにして持たせるのか、について自ら確かめるためであった。
グーグルには Xxxx Xxxxxxxx という Google Health プロジェクトの責任者がいた。彼は XML や Internet Explorer や Microsoft Access を開発した頭脳明晰な人だが、医療については何も知らなかった。例えば、グーグルは最初のプランの中で、患者が未xx者の
場合は家族が情報を共有すべきだ、と考えていたが、未xx者が、妊娠や堕胎や心の病に
ついて医師に相談する場合、これを家族と共有するのは問題があるということを、Dr. Xxxxxxx はグーグルに助言した。10 名のアドバイザリメンバーからなる検討委員会で討論し、グーグルは未xxの患者の医療情報を家族と共有することは認めないことに決めた。将来は、代理権のようなものを提案し、自分の記録を誰かに見てもらうように招待したり、その招待をいつでも中止できるようなことを考えている。同じことは、親が病気で老齢の場合にも考えられる。
Dr. Xxxxxxx がグーグルのアドバイザリメンバーに加わったもう一つの理由は、規格の問題であった。Dr. Xxxxxxxは HITSP（Healthcare Information Technology Standards Panel、医療情報標準規格を定義する米国の団体）の議長を務めており、グーグルが医療機関の意向を尊重するように働きかけた。
【概要】
a) Google Health へのアップロード
患者は、Google Health を使えば、患者自身の全ての医療情報を一ヶ所に集め、患者自身がそれを管理することができる。患者はまず Google Health にログインし、ベスイスラエル病院の医療情報を Google Health に集めるために Google Health の画面から PatientSite にリンクすることになる。この場合、患者は PatientSite のログイン画面で、PatientSite から発行された証明書（ID とパスワード）を使ってあらためてログインしなければならない。接続先がクリーブランドクリニックや Walgreens や Quest などであっても、同じように、それらの病院が発行した証明書を使ってログインすることになる。
次に患者は、PatientSite にある患者自身の医療情報（診断、投薬、アレルギー）の中から患者自身が望むデータを選び、アップロードのボタンを押すことにより、Google Healthへアップロードすることができる。患者がデータをアップデートすることを望むか望まないか、さらに望む場合はどういう情報をアップデートするか、それは患者自身が自分の意志で決めて行うことになる。
その結果、患者はウェブ上の Google Health の画面の中で、アップロードされた全てのデータを見ることが可能になる。グーグルは約 1 千万ドルのお金をかけて、SafeMed という会社と組んで、医師が記録するときに使用する、IDC9 や SNOMED、MeSH、LOINC などのあらゆる医療用語のマッピングを行った。従って、アップロードされたデータは、用語が整理された形の情報となって画面上に表示される。
b) Google Health で患者が可能な事
PatientSite から一旦 Google health にデータが移されると、患者は様々なことを行うことができる。もしアップデートしたデータの中にさらに詳しく知りたいものがあれば、それがどういうものであるのかという情報を、グーグルからダイレクトにリンクさせて調べることができる。ちなみに、グーグルの健康関連の検索は 1 日当たり 1 億件にも上る。また、例えば、85 才で 10 種類の薬を服用している患者がいて、これまでは薬が必要な時期を自分で管理し、毎回電話をかけて薬を入手していたとする。このような患者は、もし ePillBox というサードパーティの会社に登録しておけば、薬が必要になったときにその会社が毎回メッセージを送ってくれることになる。さらに、患者が救急病院へ行くことになったとき、救急病院には患者の医療記録がないので、Google Health の中にある自分の医療記録をクリックし、救急病院へファックスを送ればそれを使うことができる。 Google Health にデータをアップロードした後、患者はそのデータに注釈を追加して編集することができる。また、不必要なデータを削除することもできる。ただし、書き換えることはできない。何故なら、例えば、患者のデータがベスイスラエル病院の PatientSite から Google Health を通じて他の医療機関へ送られる場合、ベスイスラエル病院で行われたことを正しく伝えなければならないからである。
c) Google Health のセキュリティ
ベスイスラエル病院はグーグルと契約を結び、データがどのように流れるのか、それがセキュリティ的に正しいことをどうやって確認するのか、いかにデータを安全に保つのか、について保証を取った。Google Health には個人を特定するという概念がないことが分かった。
患者は Google Health のプライバシーポリシーを信頼して利用する。もし、患者のプライバシーが破られることがあれば、患者はそこにデータを置こうとは思わない。従って、グーグルは自らそして自分たちのパートナーのプライバシーポリシーに対して非常に厳格に対処している。例えば、グーグルはサードパーティの会社がプライバシーに配慮していることをレビューし、情報が転送されたり、売られたり、データが攻撃されたり、広告に使われたりしないようにしっかり監視している。
米国には、患者の記録を保護する HIPAA （ Health Insurance Portability and Accountability Act）という法律がある。この法律は、病院や開業医、保険会社だけをカバーするもので、グーグルのような会社はカバーしていない。従って、一部の人たちに、
グーグルはデータを売ったり広告に利用したりするのではないか、という心配があった。法的にはグーグルは HIPAA の外にある、それ故、Google Health は患者の信頼の上にのみ成り立っている。議会の中には、グーグルやマイクロソフトなどの個人健康記録も HIPAAのようなプライバシー法でカバーすべきだ、という意見もある。
新聞記事に「ベスイスラエル病院がグーグルと患者データをシェアしようとしている、それは恐ろしいことだ」と出たことがある。しかしその後、「患者に透明性をもたらすやり方でデータをシェアしようとしている」、「患者が自分のデータを患者中心に管理することはいいことである」、と肯定的な表現になっていた。
d) Google Health の利用状況と今後の機能拡張動向
ベスイスラエル病院と Google Health との連携は開始したばかりであるが、PatientSiteに登録している約 40,000 人の患者のうち、すでに約 5,000 人が加入している。その人たちからのサポートの電話は非常に少ない、それは使い方が簡単だからである。Google Health ではさらに新しい機能を追加しようと考えている。そのひとつは、患者の病気のサポートを患者レベルで決めるようなことを提供しようとするものである。例えば、患者が糖尿病の診断を受け、ヘモグロビン A1C が 9 を示していたとしたら、Google Health 上で「あなたは血糖値を低く管理することについて医師と相談した方がいい」と表示される。これは医学的なアドバイスではなく「医師と相談しなさい」という単なるサジェスチョンである。グーグルには、医学的なアドバイスやコンサルティングを提供するビジネスをやるつもりはなく、従って、多くの医師や病院は、自分の仕事を奪われる心配がないため Google Health にリンクしようと考えるのである。
【Google Health などの外部ストレージに関して】
a) Google Health の長所
Google Health のいいところは、患者にとって使い易いという点である。ユーザインターフェースがよく考えられている。全てブラウザで動き、ウェブページはシンプルである。グーグル検索も、実際にやっていることは複雑であるが、非常にシンプルなウェブページになっている。
b) Google Health の短所
Google Health そのものの短所ではないが、グーグルの問題点は、彼らが公表したプロジェクトプラン通りにはやらないことである。これと比較すると、マイクロソフトやアイ・ビー・エムなどは、複雑なプロジェクトはガントチャート（米、ガントが発明した管理図表）を使って行う。社員 18,000 人の平均年齢が 23 才であるグーグルは、社員に対して「何かすごいことをやれ」と言うだけであり、その結果として グーグルの製品はいつまでもいわゆる β 版である場合がよくある。Google Health も同じである。グーグルに「プランはどうなっているのか？」と聞いても答えは決して出てこない。
c) Google Health 開発の実態
ベスイスラエル病院は 2008 年 5 月 19 日より Google Health との連携を始めたが、それは挑戦的な出来事であった。5 月 19 日当日の朝 9 時に最初の総合テストを行い、その日の昼にサービスを開始するというとんでもないスケジュールであった。グーグルの開発の出来具合は、プライバシーやセキュリティに関しては本当にいいものであったし、このプロジェクトはうまく遂行されたのだが、このような開発プロジェクトの経験はベスイスラエル病院にとっては初めてのことであった。ベスイスラエル病院としては、前もって 1 か月間はコードを凍結し、多くのユーザによる受け入れテストを行った後にサービスを開始したいと考えていたし、プロジェクトプランは広く連携を取りながら進められるものと思っていた。Dr. Xxxxxxxは現在も Google Health プロジェクトに加わっており、SafeMed の役員でもあるが、グーグルから次のリリースがいつ出てくるのか知らないと言う。もし誰かが、グーグルと一緒に仕事をしようと考えるのであれば、ソフトウェアは非常にいいものができるが、グーグルとコミュニケーションを取ることは容易ではないのでフラストレーションが溜まるであろうと言う。
Google Health がリリースされたとき、最初の 5 分間で 100 万人が使ってみようとした。グーグル検索では 50 万のサービスを持っているが、Google Health ではたった 5,000 のサービスを展開しただけである。もしグーグル検索と同じようにサービスを準備し、そこへ 100 万人が同時に医療記録をアップロードしようとアクセスしていたら、Google Health は簡単にパンクしていたかも知れない。
d) Google Health と Microsoft HealthVault との比較
Google Health と Microsoft HealthVault との利用比率は 10 対 1 くらいである。Googlle Health はユーザ（患者）にフルアプリケーションを提供しており、患者は自分の健康の問題に自分で注釈をつけることができるし、医療記録の何を表示し何を表示しないかについて自分で簡単に決めることができる。それに対し Microsoft HealthVault は健康情報のまさに保管室（vault）であり、単にドキュメントを溜める場所である。それはアプリケーションではなく、ユーザインターフェースはユーザが使い易いものではないため、使うユーザにはフラストレーションが溜まる。マイクロソフトは自ら「我々は保管コンテナであり、優れたアプリケーションをつくることはサードパーティに任せる」と言っている。グーグルで、Google Health に携わっている人数は 12 人である。一方、マイクロソフトで、Microsoft HealthVault に携わっている人数は 400 人である。マイクロソフトは非常に素晴らしいプロジェクト管理を行い、コミュニケーションは非常に容易い。しかし出来上がったソフトウェアはいい出来とは言い難いことが多い。例えば、Windows Vista には 1 億ドルもお金をかけたと言われているが、ソフトウェアの完成度についての評価はそれほどでもない。Google Health はまさに PHR であるが、Microsoft HealthVault は単なる保管コンテナである、というのが Dr. Xxxxxxx の評価である。
Dr. Xxxxxxx は、もしこの 2 社と一緒に仕事をするのであれば、グーグルは一緒にやるのは大変だが素晴らしいソフトウェアを作り、マイクロソフトは一緒にやるのは容易いがいいソフトウェアは作らない、ということを念頭に置いておくべきだ、という忠告を付け加えた。
【Google Health のビジネスモデル】
a) グーグルの広告ビジネスモデルとの関係
グーグルの広告ビジネスモデルと、Google Health の PHR は明確に区分されている。 YouTube や Picasa のようなサービスのインフラは、Google Health のインフラとは切り離されており、従って、セキュリティについては安心できる。現時点では Google Health を通じた広告やサービスなどのビジネスモデルの動きはない。しかし、Google Health が将来どのような展開を見せるのかは分からない。ベスイスラエル病院の PatientSite は Google Health と連携しているが、ここにグーグルの広告ビジネスが入り込むことはあり得ない。
b) Google Health ビジネスの動向
グーグルは Knowles Project と呼ばれるプロジェクトを持っている。これは Google health の上に薬の Wikipedia のようなものを作ろうというプロジェクトであり、 Wikipedia と異なる点は、誰でも書き込んだり編集したりできるのではなく、グーグルが認定した専門家だけで行うことである。Google Health 上に医師団によって編集された薬に関する膨大な数の記事を作ることをグーグルは目論んでおり、それは、オンライン参照を提供している UpToDate みたいなものであるが、UpToDate は有料なのに対し、 Xxxxxxx は無償で提供しようと考えている。
現時点ではグーグルは医療記録をシェアすることはしない、と言っているが、今後の傾向として、公的な健康情報提供のために、個人を特定しない何かをやるかも知れない。例えば、インフルエンザの統計みたいなもので、Google Health に入っている人の中で今年何人がインフルエンザにかかったか、とか、何人がインフルエンザの症候を報告したか、というようなものである。
Google Health とは直接関係ないが、Cleveland Clinic では MyConsult というセカンドオピニオンサービスを有料で行っている。これは収入源になるので、ベスイスラエル病院としても将来は加えたいサービスになるであろう、と Dr. Xxxxxxx は付け加えた。
1.3.6 連携パートナーの動向
a) Google Health
Google Health はベスイスラエル病院とクリーブランドクリニックを最初のパートナーとして始め、他のパートナーも増やしているが、今のところ国際的なパートナーまでは考えが及んでいない。しかし、グーグルは国際的な会社なので、Google Health が全世界に広がっていくことは自然なことである。Dr. Xxxxxxx は Xxxxx や Missy のような国際的な連携プロジェクトを進めている会社をよく知っており、これらの会社との連携を Google Health に推薦したいと考えている。
b) Microsoft HealthVault
マイクロソフトもグーグルと同じような素晴らしい会社なので、ベスイスラエルは PatientSite の連携先に Microsoft HealthVault を追加した。PatientSite のユーザは約 4 万人いるが、彼らは Google Health でも Microsoft HealthVault でも選ぶことができる。Microsoft HealthVault へのデータのアップロードのやり方は、Google Health へ
のやり方と同じである。また、Kaiser Permanente は約 9 百万人の顧客（患者）を持っているが、マイクロソフトをパートナーとして採用することを決めた、と Dr. Xxxxxxxは言う。
c) ベスイスラエル病院の連携に対する考え
ベスイスラエル病院としては、患者が Google Health と Microsoft HealthVault のどちらを選んでもいいと思っている。ベスイスラエル病院はさらに Dossier のようなところとも連携してもいいと思っている。 Dossier は Walmart、PetDepots、GE のような多くの企業に従業員用として使用されている。そこでは多分、CCD や CCR のような規格が使われているであろう、と Dr. Xxxxxxx は言う。
ベスイスラエル病院では、信用できるのであれば他の PHR ベンダーも使おうと考えている。ガレージハウスのような小さい会社は信用できないが、例えば、America Online を辞めた Xxxxx Xxxx が始めた Revolution Health や MedMD のような会社とは、将来は連携する可能性がある、と Dr. Xxxxxxx は付け加えた。
1.3.7 RHIO（Regional Health Information Organization）
a) 米国における RHIO の現状
米国では RHIO のような地域連携医療（病院間の患者医療情報の共有）は必要であり、PHRのデータ共有はもっと加速すべきである、という議論があるが、RHIO の採用は非常にゆっくりした動きである。その最大の理由は、患者が RHIO を特に必要としていないことである。病院は患者の医療記録を患者に渡し、患者はそのデータを別の病院に渡すことになるが、患者は全てのデータを共有する必要性までは感じておらず、自分が必要と判断するデータのみを共有しているのが実態である。PHR を利用しない患者にとっても、RHIO によって病院から患者へ、そして患者から別の病院へと自分の医療記録を共有することができる訳だが、プライバシーの課題もあって、患者への浸透は思うように進んでいない。医療サマリについては、RHIO をスルーして、病院から病院へ送られている。
RHIO のソフトウェアは、RHIO が開発したもので、それは簡単なソフトウェアであり、 全 ての病院や保険会社はそれらを持っていて、ベスイスラエル病院でもこのお蔵入りになり かけているソフトウェアを使って XML ストリームを流している。RHIO にはお金がなく、ソフトウェアを改良する特別な計画を持っていない。連邦政府や州に働きかけて医療情報 交換のためにお金を出してもらえるように話をしているが、政府はお金を出してくれない。
英国やスカンジナビアの国々は電子カルテや医療情報交換に何億ドルもお金を出しているのに、と Dr. Xxxxxxx は言う。
b) ベスイスラエル病院の RHIO への取り組み
ベスイスラエル病院はマサチューセッツ州の RHIO に参画している。マサチューセッツ州では、何を共有し、どのようにして患者の同意を得るか、という課題があり、とくに外部の医師や病院に対し用心深くなっている。従って、ベスイスラエル病院の医師は、患者が必要とする時に限りデータを使うということを固く守っている。米国には 1,000 もの保険会社があり、ベスイスラエル病院はこれらの会社と間で年間約1 億件の処理を行っている。マサチューセッツ州では RHIO が同じことをやってもいいようにした。しかし、全ての病院と保険会社を繋ぐこと、つまり病院と RHIO を繋ぎ、RHIO と保険会社を繋ぐことは大変困難である。
マサチューセッツ州の RHIO への予算は大変厳しく、2008 年は大幅赤字で 2009 年も予算がつくかどうか分からない状況であり、従って、ベスイスラエル病院では RHIO の恩恵に与る保険会社や病院から RHIO 活動のための資金を手に入れようと考えている。ベスイスラエル病院では、8 百万ドルをかけて、同じ地域の開業医に電子カルテを提供するためのデータセンタを建設した。いい品質の医療を患者に届ける唯一の方法は、医療データが地域内に行き亘るようにすることである、という信念のもとに実施した。これにより、RHIOを通じて電子カルテが繋がり、開業医と病院が情報を交換できるようになった。開業医がベスイスラエル病院の電子カルテを使うことにより、開業医が自分の患者をベスイスラエル病院へ送り込みたいと思うようになり、まさに連携医療を実現する共同体のようなものが出来つつある。ベスイスラエルでは、このような地域の医療機関には、ベスイスラエル病院の全ての電子カルテデータにアクセスすることを認めている。一方、遠くにある病院に対しては、 RHIO を使って医療情報を要約したものを提供するようにしている。
c) RHIO と Google Health の連携の可能性
Dr. Xxxxxxxの意見では、RHIO はハブやスポークのようなもので、病院から受け取った医療情報を、RHIO が Google Health へ送るようなことは実際にはないようだ。 XXXX は本人認証に関する戦略を持っていないし、データを保管するインフラも持っていない。現時点で RHIO は Google Health と連携して何かをやろうとはしていない。
1.3.8 規格
現在、米国で現実にインプリメントされている医療情報規格は、
1) CDA（Clinical Document Architecture）: HL7 協会策定✰医療情報規格
2) CCR (Continuity of Care Record) : ASTM（米国材料試験協会；American Society for Testing and Materials）が策定した医療情報規格。CDA に比べて非常にシンプルである✰が特徴（xxxx://xxx.xxxxxxxxxxxx.xxx/x000.xxx）。
3) CCD (Continuity of Care Document): CCR を HL7/CDA Rel.2 で表現したも✰
✰３つがあり、CDA が最も普及している。
a) Google Health ✰動向
グーグルは Google Health と✰連携にシンプルな XML である CCR を採用した。グーグルで働いている人たちは医療✰知識を殆ど持っていなくて、米国✰全て✰病院が CCR を使っていると思っていたらしい。Dr. Xxxxxxxは HITSP（Healthcare Information Technology Standards Panel、医療情報標準規格を定義する米国✰団体）✰議長をやっていて、Google Health ✰開発段階でグーグルに対し、米国✰ほとんど✰病院は、CCD や CDA を使いたいと思っている、と説明した。しかし、グーグル✰技術者に医療✰ことは分からず、CDA などは見たこともなく、それを理解することができなかった。ウェブ技術に長けているグーグル✰技術者にとって、CCR は RSS と同じようなも✰で、開発は簡単であった。結果的にグーグルは、最初✰データ送信方法として CCR を使うことを決め、Dr. Xxxxxxxもこれに従うほかなかった。実際✰ところ、グーグルは、さらにシンプルなサブセットを作成し Google Health にインプリメントしている
（xxxx://xxxx.xxxxxx.xxx/xxxx/xx-XX/xxxx/xxxxxx/xxxx_xxxxxxxxx.xxxx）。
グーグルは Google Health を立ち上げたことで医療へ✰理解が進み、2009 年にかけて、現在✰も✰を HL7 ✰ような構造にすることをコミットしている。
b) Microsoft HealthVault ✰動向
マイクロソフトは、Microsoft HealthVault 開発当初は、まず HL7 ✰構造から始め、すぐに CCD と CDA をサポートしようという考え方であった。現在は CCD を使用しているが、将来的には CDA を使いたいと考えている。
Kaiser Permanente は、マイクロソフトが HL7 アーキテクチャを採用したという理由だけで、Google Health ではなく Microsoft HealthVault ✰方を選んだ。
c) ➴スイスラエル病院✰規格に対する考え方
現在➴スイスラエル病院では、内部✰医療記録には CCD を使っており、それを Google Health 向けに出すときには CCR を使い、Microsoft HealthVault 向けにはそ✰まま CCDを使っている。政府関連機関、例えば SSA（Social Security Administration、米国社会保障局）に送るデータには CCD を使用している。けがや病気で長期間働くことができない患者は、SSA に申請して手当をもらうことになるが、年間で 5 億ドル✰お金が、病院から送られてくるこれら✰医療記録を基にして支払われている。
グーグルもマイクロソフトも、将来的には CDA を使いたいと考えており、➴スイスラエル病院も PHR には CDA を使う方がいいと考えている。
現在➴スイスラエル病院では、様々な CCR をマイクロソフトに送り、Google Health と Microsoft HealthVault ✰間✰伝送✰編み直しをやってもらうことを進めているが、両者
✰セキュリティ✰やり方が全く異なる✰で、うまくいっていない。そ✰ため、➴スイスラエル病院独自で、Google Health 用✰インターフェースと Microsoft HealthVault 用✰インターフェースを別々に作り運用している。
現在第三✰連携先として Dossier も検討しており、Dossier 用✰インターフェースも作ることになる。しかし、これは全く馬鹿げたことであり、ひとつ✰処理方法、ひとつ✰伝送規格、ひとつ✰セキュリティモデルにして、あらゆる PHR を接続できるようにすべきであると考えている。
米国には、グーグルやマイクロソフトに標準規格を使うことを強いる法律がない。FDA
（Food and Drug Administration）や CFDC（Centers For Disease Control）を通じて、連邦政府に規格を統一しこ✰ひとつ✰規格を使う要求を出しているが、連邦政府側は CDAを選ぶに違いない。しかし、グーグルやマイクロソフトが何を選択するかは分からない。
➴スイスラエル病院では、研究機関向け✰ LOINC ➺ード、診断用✰ IDC9、投薬用✰ MDC
➺ードなども手がけており、さらに CCD パッケージ✰ SNOMED という問題リストも使うことになる。2009 年には、CCD 以外にもサービス志向アーキテクチャに取り組んで、Google Health や Microsoft HealthVault 向け✰➺ンポーネントを作ることになるであろう、と Dr. Xxxxxxxは言う。➴スイスラエル病院は CCR を推進する ASTM とは特別な連携は取っていない。
d) そ✰他✰民間会社✰動向
ミニッツクリニック（MinuteClinic）という米国では最近よく見るようになった新種✰診療所✰ような所がある。これは、ちょっとした頭痛や咳や寒気を訴えたときに、ドラッグストアが 50 ドル✰費用で、喉✰痛みには抗生物質を、インフルエンザにはワクチンを提供するも✰で、CVS ドラッグストアはこ✰ような所を米国内に10,000 か所も持っており、ここでは CCR が使用されている。彼らは、蓄えてあるこれら✰ CCR データを、最終的には、一次医療機関に返したいと希望しているが、現在はまだ実現できていない。患者は、ミニッツクリニックから✰ CCR データを Google Health を経由して手に入れることができる。
e) openEHR について
Dr. Xxxxxxx ✰考えでは、openEHR はアイデアであり規格であって、実際に使えるソフトウェアではない、という理解である。ただ、オープンソースという考え方は重要なことでありそれを使うことは基本的に良いことであり、基本原則、規格を持ち➺ーディングされる openEHR という考え方で、医者による医者✰ため✰電子xxxが安く開発されることはいいアイデアである、と思っている。
オープンソース✰例として、VistA という政府系✰旧い病院があり、そこが病院や開業医向け✰電子カルテを開発し、現在は無償で提供している。しかしこれを使用している病院は医療請求書を発行できないという問題があり、そ✰ため、あまり使われていない。また、 Medsphere や WorldVistA という会社がそ✰ようなオープンソースを改良して、多く✰医者が使い始められるような、より使い易いも✰をより安く提供できないか、とトライしている。
多く✰病院は、オープンソースソリューションが安定したも✰な✰か、安全なも✰な✰か、ということを心配しており、従って、高くつくが Siemens、GE、Cerner、Epic など✰専用ではあるが安定したソリューションを選んでいる。
1.3.9 米国✰医療行政など✰動向
xxx氏は大統領選挙期間中に、医療情報技術に50 億ドル支出することを提案している。これは国家予算✰わずか 1％である。しかし、他✰予算は殆ど全て確定していて、国✰財政赤字も非常に顕著である✰で、xxx氏が医療情報技術を重視したとしても、実際に財源を確保できるかどうか分からない状況である。
議会予算局（Congressional Budget Office、CBO）からは「医師が電子カルテを買うために予算をつけることはできない」という報告が出された。しかし、政府✰法律に変化があり、Stark Law（2008 年 10 月 4 日成立）により病院が医師✰ために電子カルテを買うことが許可されるようになった。しかしこれは、医師✰ために政府がお金を出すという話ではなく、お金を負担する✰はあくまでも病院側である。
2009 年か 2010 年には、電子処方箋を書かない医師や電子カルテを持っていない医師にペナルティを課すようすることを、政府が検討している。また、医療業務✰電子化を進めるひとつ✰アイデアとして、電子的なシステムを使う医者に対し、そ✰情報を使って儲けている保険会社が、インセンティブを出すようにすればいい✰ではないか、さらには、連邦政府や州政府、民間✰保険機関が医療情報技術に対してお金を出してくれるようになると医療業務✰電子化は加速するはずだ、と Dr. Xxxxxxx は期待を込めて言っている。
1.3.10 EHR ✰➴後
マサチューセッツ州では、1 年間で 30 億ドルが医療に使われていて、そ✰内✰ 15％✰ 4億 5 千万ドルが余分な検査に使われているという。病院間でデータを共有しないから同じ検査が行われる訳で、RHIO や Google Health などにより病院が患者とデータを共有することによって、患者が苦痛を伴う不必要な検査を回避したり、薬✰事故を回避できるようになる。ただこれにより、病院は患者を失い、収入を減らすことになるが、例えばマサチューセッツ州✰全て✰病院は非営利である✰で、あまり気にならないと言う。こ✰あたりは、余分な検査を省いていい医療を行えば病院✰収入が減り、データを共有してしまうと患者が盗まれる、と考えている日本✰医療とは違うところである。
これから先 2 年くらい✰間で、患者から✰データ共有へ✰要求に応えられない病院は患者を失うことになるだろう。