医療×ブロックチェーン⑤ 医療データ標準化問題

Pocket

医療データ標準化問題(異なる電子カルテ間の医療データ互換構築問題)
 
多くの医療系ブロックチェーンで記載されている「研究者が患者データを集計・分析するために患者に対して仮想通貨を支払う」というビジネスモデルを成り立たせるためには、患者データを容易に集計できなければならない。
 
具体的には、検索クエリを投げたとき(例えば「HbA1cが7-8の間にある人で、メトグルコを内服している人」など。文章検索 or キーワード検索)に、該当する患者さんを電子カルテから引っ張り出せなくては意味がない。
 
しかし電子カルテが乱立している場合は、患者データの保存形式が標準化されていないので難しい。
 

ここでいう医療データ保存の標準化とは、具体的には

1)記入ルールの統一
データベースのカラムに入れる内容を統一しましょう(薬品名・処置内容など)
 
2)用語の統一
GAMMA-GTPとγ-GTPは、γ-GTPと統一しましょう
 
3)保存フォーマットの標準化
CT画像などのフォーマットを統一しましょう(DICOM or JPEGなど)
 
である。これらが統一されないと、例えば「γ-GTP>100の患者」と検索をかけても「GAMMA-GTP」で入っている患者さんは検索対象外になってしまう。
 
というわけで、電子カルテが絡む医療系のブロックチェーンを成り立たせるためには、電子カルテの医療データ標準化問題は避けては通れない。ここでは、アメリカ・日本・ヨーローパの医療データ標準化の経緯を見ていく。
 
1990年台半ば(結構歴史長い!)より、医療データ標準化構築の検討は各国で始まった。

・米国:HL7→FHIR(医療 IT 標準仕様フレームワークFHIR互換性を表示する電子カルテが増えてきている)
・日本:SS-mix2(米国のFHIRに準拠)
・ヨーロッパ:openEHR

 
 
医療データ標準化構想から20年弱すぎているが、そもそも
①各国での標準化構想に倣っている民間の電子カルテ会社が少なく


②各国で標準化を達成したとしても、次は国間での標準化を達成しないといけない。
 国による法律、習慣、運用などの違いから、結果的に多くの規格が発生し、唯一の標準を作ることは困難
 
という二重のハードルがあり「世界で唯一の標準構想」は現実的に困難な状況である。 ①に関しては、電子カルテ会社が標準化に合わせるメリットがなく、②に関しては標準化の覇権争いになっている。
→なので、データ共有型(各医療機関の医療情報を、一定の形式に変換して共有する方式)を採用せざるを得ない。
 
 
こちらのアメリカの医療系ブロックチェーンに関する記事では、ほとんどのヘルスケアブロックチェーンがFHIRに依存していることを問題視している。
「FHIRは医療標準規格として第三者機関が主体となって進めているが、大病院を除いては採用しているところはほとんどない。
 
FHIRのCEOは
電子カルテ側に何もメリットがない点が根本的な障壁だ。電子カルテメーカーは「どうして、弊社が標準化にわざわざ準拠しなければいけないんだ?我々は競合の電子カルテから医療データを死守してきたのに、標準化して他の電子カルテメーカーとも共有するなんて、メリットなさすぎてわざわざそんなことする必要ないでしょ?」と思っている」
と半ば自虐的に話している(2017.11)
 
ブロックチェーンを介したPHR構想の前に、現状立ちはだかっている医療データの標準化問題、具体的には各電子カルテメーカーが積極的に医療データ蓄積の標準化に動いてくれるインセンティブを提供できるかという問題を認識すべきだ。
 
 
これは日本でも同じ状況で
 
例えばレセコンでは日本医師会が進めているORCAがあり、APIとしてソースを公開して「各電子カルテメーカーの皆さん、API公開しているので是非ORCAレセコン対応で開発してね。そうしたらレセプトデータも標準化されるよ」と呼びかけていてオープンな思想自体は素晴らしい。
 
しかし現実的には、ORCAに対応している電子カルテは新進気鋭のクラウド型を中心とした電子カルテばかりである(大手で入っているのは在宅でシェアを伸ばしているM社くらいか)。
 
日レセ連携電子カルテ一覧は、こちら(このサイトを見て、電子カルテ会社ってこんなにあるんだとビックリした。)
病院向け大手のF社・N社や、クリニック向けでシェアを取っている、P社・H社・D社などは対応していない。自社でレセコン一体型の電子カルテを開発している。
 
これに関して大手側がORCA非対応の理由としては
1)日レセプロジェクトが始まったのが2002年であり、大手の電子カルテメーカーはそれ以前に独自でレセプト一体型の電子カルテを構築していたので、今更仕様を変えるのは開発負担でしかない。
 
2)ORCAに対応すると、自分達がパッケージ化することで高額請求できている部分がなくなってしまうので金銭的デメリットしかない。自分たちの売上が減ってしまう。
 
3)別に他の脅威となりそうな電子カルテメーカーがORCA対応していないので、まだ様子見でも大丈夫。
 
などが考えられる。まだ脅威でもないし、自社でレセプトも開発しているからインセンティブがそもそもない。むしろマイナスのインセンティブすらある。
 
多分、大手電子カルテメーカーもORCA対応の電子カルテの動向はチェックしていて、5年に1度程度の大幅な機能改善の際に、ORCAに対応するかどうかの議論は上がるのだろうが、まだ大丈夫とか、優先順位は低いよねなどの結論になり、どの大手も非対応どまりになっていると推測する。
 
一方、クラウド型や、新規参入した電子カルテ会社は
・ORCA対応を謳うことで、日本医師会のお墨付きを得てプレゼンスを高めたい
・低価格にすることで大手との勝負に持ち込みたい
 
などといった思惑が働くので、どんどんORCA対応する。
しかし
1)電子カルテはスイッチングコストが高い。そもそも電子カルテ導入や切り替えを考えるタイミングが、新規開業の時もしくは今の電子カルテの保守が切れる時であり、5年に1回ほどしかない。
 
2)日々使うシステムなので、運用保守が一番気になるところであり、ベンチャーには大手の安心感と同等のレベル(24時間365日サポート体制など)を提供することが人的にも難しい。これに対して、低価格で勝負しようとしても「安かろう悪かろう」にも取られてしまうので、なかなか難しい
 
などといった理由から、新規参入して大手の牙城を崩すことは想像以上に困難である。to C向けのサービスが一気に業界をdisruptする感じはなかなかなりにくい市場になっている。
 
こういった理由から、日本医師会のORCAプロジェクトの思想自体は大変素晴らしくてもレセプト部分ですら標準化が進まない。大手側が対応するインセンティブが全くないのだ。
 
 
電子カルテの標準化に関しては、SS-MIX2(厚生労働省電子的診療情報交換推進事業。漢字長い!)なるものがコンソーシアムとして2007年に立ち上がっている。
 
下記のようなシステム構成であり、簡単に言えば「電子カルテメーカーの皆さん、医療情報を標準化したいのでSS-MIXという標準化したストレージに対応して開発してくださいね」という呼びかけである。標準化できたら、患者データを電子カルテ横断的に引っ張ってきて、集計分析できるようになるので良いよね、と。
 
(出典:http://www.ss-mix.org/cons/ssmix2_about.html
 
 
で、11年たった現在SS-MIXに対応している電子カルテは3社のみ、導入病院は1360のみという現状である。1360は純粋にすごいと思うが、まだそれでも全国10万施設の1.36%である。
 
 
あとこちらの記事によると、「病院へのSS-MIX2 モジュールの導入と診療情報データベースの構築には、最短でも概ね 1 年間程度の期間は必要となる。」と記載があり、導入するまでの期間も相当かかる(実際は多分3倍の3年はかかる)
 
また、電子カルテがそもそも標準化に対応していない場合は、誰かが標準コードに対応づけるための作業(以下「マッピング業務」)を行う必要があるが、これは手作業でやる(GAMMA-GTPはγ-GTPを表すなど)必要があり、電子カルテメーカーはやりたがらない。そして、医薬品、検体検査等を表す電子カルテシステム内のコードは通常、病院独自のローカルコードで運用されているため、この観点からもマッピングは必要である。
 
このマッピングであるが、特に検体検査のマッピングは医学的に高度の専門知識を必要とする(例えば、GOT、ASTの2つの言葉が同一の検査を表すことを知っていなくてはいけない)ため、単なるSEによる作業が難しい。専門知識を有している病院の職員(検査技師等)であればマッピング作業は可能であるが、作業量が多く業務負荷が大きい。
 
こういった複数の要因(インセンティブ問題・専門職問題・手作業問題)により、マッピング業務は大変である(同じ記事にマッピング業務の大変さも記載してある。)
 
 
一方、SS-MIXより古い歴史を持つ医療情報の標準化プロジェクトとしては、2001年から続いている「Dolphin Project」(現在は「千年カルテプロジェクト」)がある。こちらは、MML(Medical Markup Language)というSS-MIXとは違う標準規格を進めており、標準規格でも乱立する形になっている。
 
こちらの記事では
「実際は、日本国内でも海外でもさまざまな規格が乱立しており、これらを変換(mapping)して一つのデータベースに収容する方法がとられている。mapper専門の企業(オリオン ヘルス社)が世界を席巻している現状からも「唯一の規格」が現実的ではないことがわかる。」

と記載されており、もはや、標準規格なんて無理なので、様々な規格に変換できる変換プログラムのみに特化してAPIを開発して、全ての電子カルテの独自の規格にも対応できる黒子的な企業を日本でも立ち上げた方が、急がば回れじゃないけど、結果的に医療情報のintegrationが早いのではとさえ思えてくる。

(ちなみにOrion Health社のmapperソフト「Rhapsody」の説明はこちら。アメリカの標準規格であるHL7だけでなく、CCDA, NCPDP, X12, IHE, DICOM, XML, binary, delimited and legacy formats.まで対応しているらしい。and legacy formatsって笑)
 
ORCAもSS-MIX2も、アメリカのHL7もそうだが、こういった医療情報の標準化を進める際はコンソーシアムもしくは中立的組織である必要があり、その点では正しい(というか、おそらくそうせざるを得なかったのだと思う)。 どこか1社の電子カルテメーカーが「うちの電子カルテの医療情報管理DBにみんな合わせてくれ」なんて声かけたとしても、他の誰も便乗しない。特にシェアが乱立している状況では。ただ、中立的組織にしたとしても、さらに各電子カルテメーカーが参画するための金銭的インセンティブがないとなかなか広まらないのはすでに見てきた通りだ。
 
googleですら、googleヘルス構想は失敗してプロジェクトを終了している。 一般ユーザーや各病院がgoogleのクラウドストレージに医療データをアップロードして、医療情報を一元管理する試みのプロジェクトだったが、一般ユーザーへ広く使ってもらえなかった+各種企業や病院とのアライアンスを組むことができなかったなどが理由で終了したとのこと。googleヘルスの失敗の記事はこちら
 
これに関してMediBlocは「自社で医療データを抽出できるAPI・SDKを各々の電子カルテに対応して開発します」とwhite paperに記載していたが、実際の講演の際には、この部分が一番大変と言っていた。確かに電子カルテメーカーにメリットがないので、その交渉を一社一社地道に進めるのはとても大変だろう。
 
こうした中、日本、アメリカと比較して、ヨーロッパでの医療データ標準化の取り組み(openEHRと呼ばれている)は比較的うまくいっている様子だ。でも、こちらも地道に草の根活動をして対応電子カルテを広げている様子である。

次はビジネスモデル問題について

 
 
 
Pocket