2015-10-18

USのヘルスITの取り組み(11) アメリカのヘルスIT戦略

今回はFDASIA Health IT Report を翻訳するのはお休みして、アメリカのヘルスIT戦略についてまとめてみた。

米国が国民皆保険ではないことはご存じのことだろう。では、米国民はどのような医療保険に入っているのか。

まず、連邦政府が運用主体の保険は、65歳以上の高齢者や身体障害者向けのメディケアと、低所得者向けのメディケイドと、軍隊保険がある。これらの加入率は約27%だ。

軍隊保険についてひとつトピックスがある。2014年に退役軍人病院で待機患者を実際よりも少なく見せるという不正が発覚した。政府はこの問題を受けて退役軍人省の改革法案を成立させ、163億ドルの予算をかけて退役軍人病院の予約システムを改善し遠隔医療サービスの提供を行うこととした。

連邦政府が運用主体の保険制度についてはトップダウンでの改革がやりやすい。退役軍人病院の予約システムの不正の発覚は、ヘルスIT改革を進める上ではちょうどよいきっかけだったのかもしれない。

米国でもっとも加入率が高い医療保険はマネージドケア組織による保険だ。HMO、PPOといったマネージドケア組織は多数の保険加入者を抱えており、グループ内でかかれる医療機関に縛りをかけるなどして患者を抱え込むことで利益を確保している。マネージドケア組織の保険の加入者は約50%である。

次いで、一般保険者が7%、無保険者が16%と続く。無保険者はオバマ大統領の肝いり政策で極力減らす方向に傾いている。

アメリカの診療報酬の支払い方は、1983年より疾患別定額払い制となっており、オバマケアで政府が支払う医療費は治療開始から完治まで一定額で、かつ、その分配さえも医療の供給体制の関係者で決めることになった。

これにより、患者の疾患に対して平均以上の治療効率を挙げなければ病院は利益が出ないようになった。また、疾患に対する診療報酬の分配も自分達で決めなければいけないので、必然的にオペ室も病棟も薬局も協力して無駄を減らし効果を挙げなければいけなくなった。

日本はまだまだ診療報酬点数に基づいた出来高払いが主流だから、やったらやっただけ請求できるのに対し、アメリカでは同じ疾患に対して無駄な診療行為をやればやるほど病院が損するようになっている。

どうしてそこまでやらないといけないのかは、米国の医療関係費用を見れば分かる。アメリカでは2010年の時点で医療関係費用が2.6兆ドルにも達している。

この金額がいかに大きいか日本と比べてみると分かる。先日2013年度の日本の医療費がはじめて40兆円を超えたというニュースが流れた。

米国の2.6兆ドルは今のドル円レートで約310兆円だ。日本の人口はアメリカの1/3くらいだから、日本の人口比でいれば、米国は年間103兆円の医療費がかかっていることになる。
単純計算で日本の約2.5倍だ。GDP比で計算しても、日本の医療費は約6.8%であるのに対し、米国はGDPの約18%だから、日本の2.5倍という数字はだいたい合っていて、アメリカの医療費がいかに高額であるかが分かる。

ちなみに、安倍政権が掲げている新3本の矢の一つ目GDP600兆円を達成した場合、国民医療費40兆円はGDP比で6.6%となり、現状から0.2%しか改善しない。40兆円の医療費は米国よりは小さい数字だけども、この費用を稼ぎ出すのは容易ではないことが分かる。

さて、米国の国民医療費 2.6兆ドルは莫大な金額であることがお分かりいただけただろう。その状況を鑑みてブッシュ政権は2004年に 医療ITイニシャチブを立ち上げた。
  1. 医療の質向上
  2. 医療費の削減
  3. 医療ミスの防止
  4. 医療データの管理コストの削減
そして、国民のほとんどが電子健康記録(EHR)を持つと共に、各自が自分のEHRにアクセスできるようにすることを目標とした。

上記の4つも目標のうち、米国政府が本気で達成しないとまずいと思っているが2の医療費の削減と4の医療データの管理コストの削減だろう。

共和党から民主党に政権が交代しオバマ政権になっても、この方針は引き継がれた。そして、2010年には、退役軍人省とメディケア向けに患者個人が自分の健康記録をダウンロードする仕組みである「Blue Button」が始まっている。1600万人が利用できる。(退役軍人省とメディカとった連邦政府管轄の部分からトップダウンで実現させたところがアメリカらしい)

アメリカの電子健康記録(EHR: Electronic Health Record)を普及させる取り組みは本気も本気で相当気合いが入っている。

2009年に制定されたHITECH法では、医療データの標準化を含めた全米の医療機関におけるEHRの普及を目指している。

その普及のための方法がなかなかすごい。

まず、EHRの導入にあたり、各医療機関や医師を対象にインセンティブ制度を導入し、詳細な要件をクリアした場合、医師では4~6万ドルを、医療機関では200~600万ドル相当を受領できるようにした。これは飴と鞭の飴にあたる。

次に、インセンティブ制度に参加した医療機関と医師には、「有益な活用(Meaningful Use:MU)」という要件を満たすことが求められ、MUの要件を満たさなかった場合にはペナルティが課される。これが飴と鞭の鞭にあたる。

この飴と鞭作戦により、米国の電子カルテの年間成長率は7.1%で世界一位となっている。

有益な活用(Meaningful Use:MU)のステージは3段階あって、現在はMU2まで来ている。2015年度は18億ドルの予算をかけて推し進めている。

MUステージ1の具体的な内容は左記のようになっている。EHRに対する電子カルテソフトに対して、さまざまな要件を満たすことを求め、MUステージ1ではその達成率を低くしておいて、ステージ2、3となるごとに達成率の目標を高めている。

この取り組みを支えるもう一つの仕組みとしてMUのチェックシステムがある。

それがこれだ。一番上にあるONCは医療IT全米調整官室で、ONCが元締めとなり、NIST NVLAP や ONC-AA を使いながら、MUの達成をチェックしている。

デベロッパーは製品を提出し、MUの達成度を調べ、製品認証を行う。

そしてパスした製品はONCによってリストされる。ユーザーとなる医療機関はここにリストされた電子カルテ製品を選択することになる。

興味のある方は、こちらのONCのページの右下に製品リストがダウンロードできるので見てみるとよい。(107Mbyteもあるので注意)

このチェックシステムは ISO 17000シリーズ(適合評価の国際標準)に従っており、勝手に独自の評価方法でテストしているのではない。

この飴と鞭とチェックシステムの戦略と、予算とトップダウンのアプローチにより、米国ではEHRの普及が加速度的に進んでいる。

現在の米国でのEHRソフト(日本の電子カルテソフトとは様相が違うかもしれない)のシェアナンバー1と2はフリーソフトだそうだ。

フリーソフトで広告収入のモデルとなっている。まさに今どきのスタイルだ。

そして小規模な病院ほどWEBベースの電子カルテシステムを選択している。

どのEHRソフトを選択しても、MUの達成率は確保されている(正確にはMUが達成されている製品をユーザーは選ぶ)ので、小規模病院は迷わずフリーソフトを選択するのだろう。

ちなみに、FDSIA Health IT Report にあった、左記のヘルスIT重点分野の外観のうち、3つめの Leverage Conformity Assessment Tools (適合評価ツールの活用)が具体的にどんなものを指すのかずっと疑問だったが、MUのチェックの仕組みを知って、これのことを言っているのだと確信した。

品質マネジメントなどプロセス基準に対する適合評価を推奨しているのだとしたら嫌だなと思っていたが、そうではなく、医療ITの標準を評価するツールのことを指していたのだ。

実際にアメリカで医療ITの標準化のしくみが戦略的に進んでいるところを見ると、このMUのチェックと適合審査のしくみは医療IT標準化の要の役割をしているように見える。

大事なのは、このチェックシステムは主観が入らず、出来ているかどうかを客観的に数字で示すことができることだ。プロセス規格の審査、監査はそもそも合格、不合格のクライテリアが明確でなく、監査管の主観が入るので公正な審査がしにくいし、何しろ時間がかかる。

自動でチェックする仕組みを構築できれば、審査もスムーズだ。逆に言えば、自動でチェックできるようなチェック項目や判定基準を作り出せるかどうかがポイントなのだろう。

そこで、ああでもないこうでもないと議論ばかりしていると、標準化は進まない。それができるかできないかの違いは、リーダーシップを発揮できる国か否かの違いなのだろうかと・・・

さて、米国では今流行りのIoTならぬ IoHT(Internet of Healthcare Things)によって、あらゆるものが医療情報でつながる時代になりつつある。

ちなみに IoT って何でもかんでもインターネットにつなげばいいってもんじゃないと常々感じている。

目的がなくちゃダメだ。つないでから何に使うかは後で考えましょうなんていうのでは大きな社会的な成果にはつながらない。

左の図では医療情報をつなぐことが医療費の削減につながるという目的と結び付いている。

その結果、アメリカではBlue Button を押せば自分の医療データをダウンロードできるようになりつつある。

これはこれから出来ることを考えるとさまざまなサービスにつながる可能性を秘めている。人間、自分の健康には誰もが真剣だ。特に年を取って資産が増えた頃に病気になったりする。過去の医療データが自分の手元にあれば、自分で自分の病気のことを調べることもできるし、病院や医師を選択する元となる情報となる。

また、普段の食事や生活習慣について、適切なアドバイスを専門家にインターネット経由で尋ねることもできる。健康という目的は健康を損なったときにはじめて真剣に考えるテーマだと思う。

これは個人の健康管理の流れをかかる費用との関係で示したモデルだ。

人は年を取っていくと病気になる。症状が現れるまでは、健康管理は自己負担で行っており、症状が出てくるとかかりつけのクリニックや病院で外来の診察を受ける。

その後、病気が悪化すると入院し、手術をしてリハビリし、退院する。

退院後は再発防止のため、通院をする。

国は入院時の医療費を削減するため疾患別支払いを推し進めたいと考えるだろう。そうなると、米国の場合と同様に、医療機関は治療効果のある機器やソフトウェア、運用効率を高めるシステムに投資をするようになる。

安ければ売れるのではない。疾患別で報酬が決まってしまうのなら、早期退院に貢献できる機器、システムの方が選ばれる。なんちゃって製品は買われない。実力が伴う製品が買われる。

左の図は、健康寿命以上の人口比率の推移を世界標準と各国で比べたものだ。

健康寿命とは介護の手助けの必要がなく自立して生活できる年齢だから、それ以上ということは、介護が必要な人口の比率ということになる。

一番左が世界の平均で、2015年段階では世界平均の約12%が介護が必要な人口の比率である。

日本の介護が必要な人口比率は今は世界平均に近いが、今後2020年、2030年、2040年と進むにつれて、その比率はどんどん高まっていく。

アメリカの伸びは緩やかだが、中国を見て欲しい。中国は2020年以降、急激に介護が必要な人口の比率が高まる。

国民の医療費の問題は先進国だけの問題ではない。新興国ほど今後の負担が深刻になる。新興国は人口が多いから介護が必要な絶対数が飛躍的に増えることになる。

 今、Health IT絡みで新規参入を画策している企業がたくさんあるが、そういう企業には左の図を見て欲しいと思う。

各国は医療費の削減が命題となっている。介護が必要な人の割合が増大することは分かっているから、各国とも国の診療報酬は診断群別の包括支払いに移行していくことはまず間違いない。

さらに、米国はインセンティブやペナルティを使って、医療費を削減するシステムに投資が進むように相当な国家予算をかけて導いている。

国民の医療費の削減は国家最優先の課題になっている。今後のヘルスIT業界にとっての最大のステークホルダは国だと思う。

次に医療機関は国の政策により、患者の在院日数を削減させ、かつ病医院運営を効率的にする危機やシステムに投資することになる。

予算は国家予算ほどではないが、医療機関の予算規模はそこそこ大きい。ただし、仮に安価なシステムを導入しても、治療効果が低い、また、実質的な運用効率が高まらないと、診療報酬が一定なので病院がつぶれてしまう。病気が治らないまま患者を放り出すことはできないので、治療効果が高く、運用効率が上がる機器やシステムでなければ、受け入れられないようになる。

最後に、個人としてステークホルダを考える。個人の予算は国や医療機関の予算に比べて極めて小さい。Nが大きく、5億人が医療モバイルアプリを利用すると言われているが、健康な人や大きな疾患を持っていない人がどれだけ医療モバイルアプリに投資をするだろうか。

数百円のアプリをいくつか買ったことがある。それっきりで使っていない。血圧や体重を管理するアプリは使われるだろうがそのアプリの利益を集めても大きなものになるような気がしない。

数は多いが数百円、数千円のヘルスアプリに投資する個人は、ゲームのアプリを買うのと同じ程度の利益にしかならないように思う。射幸心の代わりに健康に対する危機感を煽ってみても爆発的には売れず、しばらくするうちに使われなくなるのがオチだろう。

ヘルスケア、ヘルスIT産業に首を突っ込もうと考えている人々は、はやり国や医療機関といったステークホルダが何を目指しているのかをよく考えた上で、個人へのサービスとして何を提供すべきかを考えた方がよいと思う。

これから求められるヘルスIT・ヘルスソフトウェアとは、やはり基本は治療効果に貢献するソフトウェア、医療費削減に貢献するソフトウェアシステムだと思う。

それを実現するためのキーポイントはリスクベースドアプローチとインターオペラビリティ(相互運用性)であり、アメリカはそれをMUのステージを設定することでトップダウンで推し進めている。

インターオペラビリティが進み、IoHT が普及すると、自分の健康情報をダウンロード出来るようになり、それがきっかけになってさまざまなサービスが生まれる。

個人が持っているスマホやタブレットに搭載するヘルスアプリと、特定企業が提供するクラウドサービスといったちまちました範囲のビジネスは、世界で増大する医療費の削減目標から考えると何の効果ももたらさないように思える。

活動量計とスマホで健康管理というが、それが国民の医療費削減にどれだけ貢献するのだろうかと思う。

介護人口が20%を超えるような時代に必要とされる機器やヘルスソフトウェアを考える必要があると思う。

なお、必要な技術として掲げたリスクベースドアプローチをソフトウェアで実現するときに、一般的なソフトウェアの品質向上技術と同じだと思っていると大間違いなので注意が必要である。

【今回の記事の参考文献】

米国における医療ITと関連分野における取り組みの現状
ニューヨークだより 2014年11月, JETRO/IPA New York, 八山 幸司
http://www.ipa.go.jp/files/000042853.pdf

米国における医療分野のIT導入に係る動向
ニューヨークだより 2012年5月, JETRO/IPA New York, 和田 恭
https://www.ipa.go.jp/files/000001951.pdf

日医工ジャーナル 2014.10-2015.1
米国の医療保険制度の現状と日本の保険制度、医療機器開発の行方、渡辺 幸子

新訂版 医療情報システム入門, JAHIS, 社会保険研究所

FDASIA Health IT Report http://www.fda.gov/downloads/AboutFDA/CentersOffices/OfficeofMedicalProductsandTobacco/CDRH/CDRHReports/UCM391521.pdf

2015-10-09

機能安全のバカ

機能安全は安全について間違った認識を植え付ける元凶となっている。これは事実だ。だから、表題で機能安全のバカと書いた。

先日、あるソフトウェアミドルウェアメーカーがソフトウェアを売り込みに来た。営業技術という肩書きだったと思う。

「この商品はISO26262の機能安全の認証を取っているんですよ。」という。そして、IEC62304の認証も取る予定ですと来たから、「IEC 62304 の対象は医療機器ソフトウェアだから、部品で認証を取ることはできない。」と指摘した。

寝耳に水だったようで、キョトンとされてしまった。IEC 62304 医療機器ソフトウェア-ソフトウェアライフサイクルプロセスは、ISO 13485 と ISO 14971 を引用規格としている。引用規格というの参照しているという意味ではなくて、IEC 62304 に適合するということは、引用規格にも適合していることを求めるということだ。

ISO 13485 は ISO 90001 の医療機器バージョンだから、まあよいとして、ISO 14971 は医療機器のリスクマネジメントの規格であり、医療機器の世界で誰もが知っている規格だ。

ISO 14971 のリスクマネジメントでは、当該医療機器に関して意図する使用を定め、そこから想定される危害や危険状態を分析し、リスクを評価して、対策する。

要するに何をするものかを最初に定義せずして、リスク分析はできない。それなのに機能安全バカは、何に使うものかを想定せずに IEC 62304 に適合できると言う。

ようするに、ペースメーカに使うも体温計に使うのも同じように安全を実現できると言っているのと同じだ。じゃあ、車の場合は、どんな部分に使っても認証取っていれば安全で事故には結び付かないのかと思う。

これは、IEC 61508 や ISO 26262 が高いSIL, ASIL に対して、ツールやソフトウェアアイテムの認証を推奨したことの弊害だ。

その結果、信頼性と安全性を混同する輩を生み出し、「信頼性が高ければ安全なんです」とのたまう営業員を作り出した。

このしっぺ返しは、自動車業界で5年後、10年後に必ずやってくる。電気自動車や自動運転が実用化されるようになれば、信頼性と安全性が異なることから来る複雑で原因が分かりにくい事故が増えてきて、機能安全が誤解を生む弊害を作ってきたことが分かるに違いないと思っている。


これに関連する話題で IPA が「つながる世界のセーフティ&セキュリティ設計入門」という冊子を出した。ダイジェスト版が公開されている。

ここにも機能安全に偏った記述がある。

p20  (3) セーフティ機能とセキュリティ機能の高信頼化の重要性
前述のリスク低減プロセスにおいて、STEP1の本質的安全設計やリスク回避後、STEP2 でセーフティ機能とセキュリティ機能によりリスク対応する場合、その機能自体が故障したり、誤動作したりするようではリスクを低減できません。そのため、セーフティ機能セキュリティ機能に対しては、より品質の高い設計が必要となります。
セーフティをセキュリティを分けていることはよいとして、セーフティやセキュリティの対策を機能と捉え、それらは高品質設計で実現できるように書いてある。それが機能安全かぶれの思考だ。

セーフティは目標や状態のことであって機能ではない。この冊子はIEC/ISO Guide 51 を参照しているにもかかわらず、セーフティの定義が正しく理解されていない。

セーフティ(安全)とは,〔ISO/IEC GUIDE 51:1999〕※1 によれば,『受容できないリスクがないこと』と定義される。すなわち,セーフティ(安全)は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」または「許容可能リスク」が達成されていることをもって「安全」と規定される。

安全はリスクを経由して定義され,リスクはその時代,社会の情勢,環境によっても変化するため安全の尺度を一定にすることはできず,絶対的な安全を定義することはできない。そのため,製品,プロセスまたはサービスは相対的に安全であるとしか言えない。

安全は,リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは,使用者の利便性,目的適合性,費用対効果,並びに関連社会の慣習のように諸要因とのバランスで決定される。したがって,許容可能なリスクは常に見直す必要がある。技術及び知識の両面の開発が進み,製品,プロセスまたはサービスの使用と両立して,最小リスクを達成できるような改善が経済的に実現可能になったときは,特に見直しが必要である。

これを説明するのにいつも上記のスライドを使っている。

機能安全に毒されている人間は安全を機能で実現できるという方向に持って行こうとしていて、得意のソフトウェアの品質向上プロセスのアプローチに引き込もうとする。

p12 のペースメーカの誤動作の例では、、「健康や生命に関わるために故障時にも止まることが許されないものも存在します。その場合は通常のセーフティよりも強化された二重、三重の対策が求められることもあります。」などと書かれているが、通常のセーフティよりも強化された・・・というところが、セーフティとリスクの関係について理解できていない。

「健康や生命に関わるために故障時にも止まることが許されないものも存在します。」これは正しい。しかし、その後の「その場合は通常のセーフティよりも強化された・・・」がいけない。

医療機器のリスク分析では最初に意図する使用(Intended Use)を定義し、それを元に Hazard(危害の潜在的な源) や Hazardous Situation(危険状態) や Harm(危害) を想定する。

この際にペースメーカが止まるという危険状態の危害として、患者の死が想定され、設計上の対策として問題発生時には定時ペーシングを確保するような対策が取られる。

「健康や生命に関わるために故障時にも止まることが許されないものも存在する。」というフレーズは、リスクに対する対策は想定されたリスクによって変わるので、リスク対策を決め打ちしてはいけないことを注意するために使うフレーズなのに、その意味を十分に理解せずに、「対策は足らなければ強化すればよい」と言ってしまっている。

リスクは危害の重大度や危険状態が発生したり、危険状態が危害に至る頻度(確率)で評価するのであって、リスク対策を先に考えてはいけない。なぜなら、リスクが許容できるかどうかは「使用者の利便性」「目的適合性」「費用対効果」などの諸要因のバランスで変わってしまうからだ。最初に機能を持ってくると、進化した技術の適用やアーキテクチャを見直す対策などが飛んでしまう危険性がある。

「通常のセーフティ」とか「二重、三重の対策」といった言葉が出てくるのは、安全は機能で実現できるという思い込みがあり、リスク分析の概念が十分に理解されていないからだと思われる。

原発も同じ。安全対策に焦点を当てるのではなく、危害の重大度と危険状態や危害に至る発生確率を考えないといけない。安全対策を強化すれば、安全が実現できると主張することで、結果的に危害の大きさから、人びとの目をそむけてしまう。

まず考えなければいけないのは、危害の大きさと、危害状態に至る確率や危険状態が危害に至る確率だ。

原発の場合、危害が破滅的であることが分かっている。危険状態に至る、危険状態から危害に至る確率はゼロでないことが実際に事故が起こったことで分かった。まずは、初心に返って危害がいかに大きいかということと、危害の発生確率、頻度が変わったことをどう考えるのかを評価しなければいけない。

安全対策に焦点が当たってしまうと、事故が起こったら安全対策を強化すればよいと考えてしまい、危害の潜在的源を取り除くという思考を遠ざけてしまう。

安全対策にばかり視点がいくと、危害の大きさの認識が薄れてしまうことがお分かりだろうか。

だから、機能安全はたちが悪いのだ。

リスクコントロール手段はそれを追加したことによって発生するリスクを考慮をリスクマネジメントの中で求められる。(ISO 14971より) 

実際にそういうことがあるからだ。よかれと思ってリスクコントロール手段を追加したら、別な問題が起こってしまうということがある。

リスコントロール手段を冗長設計だけしかないと思っているとこういう思考になる。冗長設計はシステムの複雑性を生み、テストケースを増やし、システマティック故障を起こしやすくなるため、場合によっては冗長設計はやめてシンプルな構造にして信頼性を高める設計を採る場合もある。

総じて、ソフトウェアの品質向上プロセスで推そうと考える人達は、リスク分析やリスクベースドアプローチの概念が抜け落ちている。

p6 セーフティとセキュリティの設計の見える化の必要性
本書でいう「セーフティとセキュリティ設計の見える化」とは、複雑になりがちな安全対策やセキュリティ対応などを、第三者にエビデンスを使って論理的に説明できるようにすることを指します。見える化の目的としては、設計開発支援、第三者認証や国際規格の取得などが挙げられます。
結局、この人達は、利用者の安全が真の目的ではなく、設計開発支援や段三者認証をやりたいからこういう読み物を作ったんでしょということだ。

安全やリスクマネジメントとソフトウェアを絡めて研究する学問が成熟していないから、こういうものが出てくるんだなと思う。

アカデミアの皆さんにはそういう研究分野を立ち上げて欲しいと切に願う。

P.S.

本文と全く関係ない話・・・

10年前に書いて日経BP社から出した本「組込みソフトウェアエンジニアを極める」は絶版になり、「リアルタイムOSから出発して組込みソフトエンジニアを極める」として再版した。

Amazon の読者感想で下記のような記述があり、著者としてそういう風に考えてもらえたのがとてもうれしかった。
開発年数の浅い私(2年目)ですが、少しずつ出来ることから実戦していこうと思いました。
また、上手くいかなかったときや落ち込んだとき、この本を読み返して、モチベーションを高めています。
そう思ったら、最初の本を書いたときに、この本を紹介するサイトを作って日経BPのサイトにおいてもらったものがまだ残っていることを思い出した。

たまたま、読み返したら良く出来ていたので、みなさんにも紹介したい。

この紹介サイトは登場人物が本の物語の中で、それぞれ視点で何を考えていたのかをザッピングできるような仕掛けや、本を出版するまでの著者の日記などが書かれていて、今考えるとよくこんなサイト作ったなと我ながら関心した。(本の紹介サイドは全部自作で制作費はかかっていない)