記事
医療情報データベースの基盤整備：多角的なデータ解析のために
2016 年 59 巻 5 号 p. 277-283
詳細
2016 年 59 巻 5 号 p. 277-283
医療で発生する多種多様なデータをこれからの医療に生かすためには，まず医療データベース（DB）を構築し，次にそれを多角的に解析して，そこから得られる新しい医学的知見を医療に展開していくことが求められる。ビッグデータからの類似症例の病状探索やAIへのデータ活用，多施設医療ビッグデータの構築のためには，SS-MIX2標準化ストレージのような医療データの標準化されたデータ収集基盤の導入と，医療DBにおける匿名化手法の共通化が必要である。こうした基盤のうえに，PMDAのMID-NETデータベース事業が実施されている。また，学会などが主体となって疾患別の臨床症例登録DBも複数構築されつつあり，共通DBシステムとして多目的臨床症例登録データベースMCDRSが筆者らにより開発され活用されている。今後は生活圏データや個人ゲノムデータも情報源になり，さらに課題が複雑化するため，共通の基盤を整備していくことで効率化，質の高度化を図っていく必要がある。
本稿の著作権は著者が保持する。
医療は情報処理と患者への介入から成り立っている。診察や検査で多角的に患者から情報収集し，その情報を分析して患者に何が起こっているかを推測し，確信が持てる状態になれば，それは診断できたことになる。診断できれば次は患者に起こっていることに介入して元の健康な状態に少しでも近づけようとする。介入という言葉には嫌な響きを感じる向きもあるが，薬を出す，傷の処置をする，手術をする，生活指導や栄養指導をする，話をする，などいずれも患者のそのときの状態に対して患者の外から（あるいは患者自身を誘導して内部から）影響を与える操作を加えるという意味での，介入である。
患者からの情報収集手段も収集される情報の量も，医療の技術進歩のおかげで劇的に増え続けている。昔は，患者との対話と，触ったり聴いたり診たりして診察するだけの情報収集手段しかなかった時代もある。今は，むしろそれらがおろそかになるほど，検査機器による情報収集手段が増え，そこから得られるデータ量も人間では処理できない膨大な量になっていることはいうまでもない。
それでも患者から得られる情報は医師が正確な診断をするにはあまりに断片的でまばらで少ないのである。人間には37兆個の細胞があると推定されており1），体内には約10万種類のタンパク質があるといわれている。潜在的に極論すればそれらがすべて違う「生命活動の叫び」を違う場所で発出しており，世界の総人口の73億人と比べればわかるように，世界中の人たちのブログで発言するデータ量よりも1人の患者から発生する生命情報は桁違いに多いのである。個々の異なる叫びを聞き分けられるような観測手段が出てくると，どこにどんな変化が起こっているのかリアルタイムで突き止められるようになる。もちろんそんな検査機器，観測手段はいまだないわけであるが，それは言い換えると，患者観測によって得られる情報量はこれからまだまだ爆発的に増えるのが医療の置かれている現状だともいえる。そんな体内の膨大な情報から正常と異常の変化が得られるようになったとき，その情報は今の医療が知っている病気のどんな状態に対応しているのかを見極める（診断する）ことは今以上に難しくなる。現在病気は数千種類の病名として定義されているが，これからは一人ひとりに違う病名がつくほど診断の細分化も必要になってくるだろう。
さて，現在でも患者から収集されている情報は多岐にわたり，何か月もの長期間にわたる時系列で膨大なものもある。同じ診断がついている患者のデータを多数集めてその特徴を分析することで，これまで知られていなかった体内状態（一般に病態と呼ぶ）の存在がわかることがある。しかし，一人の患者からの情報が多岐にわたるのに対して，同じ診断のついた多数の患者データを集めて解析することは，今の医療では実は意外に難しい。なぜなら，ある特定の病気について一医療機関で診ることのできる患者の数など多くても数千人，珍しい病気であれば数人だからである。ここに医療データベース（DB）の構築と解析の必要性がある。世界中の同一疾患の患者データを大規模に解析することで，未知の知見を発見したり，今診察している患者の状態とマッチングしたりすることでまれな診断を的確に行うといったことが可能になる。
医療で発生するマルチモーダル（情報ソースが多種多様でデータ形式も意味も異なる）な患者からの情報をできるかぎり多角的に解析できるように医療DBを構築し，解析することで「医療の情報処理パート」を担おうという新しい医療への挑戦が必要な時代が来ている。本稿では，そうした医療DBの構築と利用の基盤整備について論じる。
患者の状態は一人ひとりみんな微妙に異なる。数千の病名の一つに診断がついたとしても実際にはその病気の中で患者ごとに病状の推移は異なっている。もちろん風邪や切り傷のように，そうした個人差を気にしなくてもその病気に対応した治療法を適用することで，結局は簡単に治ってしまう状態も多い。しかし，たとえば高血圧と糖尿病があって腎臓の機能も弱っている高齢者といったその人固有のバックグラウンド状態がある下で，インフルエンザにかかったとしよう。普段は健康な人がインフルエンザにかかった場合には定型的な治療をしていれば数日で治るのがほとんどであろうが，このようなバックグラウンドのある患者だと，ほんのちょっとした違いで重症の肺炎に進行したり，元々あった腎機能低下がさらに悪化して別の病気に移行したりすることがある。このようなケースでの治療方針はまさに医師の経験に基づく「さじ加減」や「わずかな変化に対する注意力の多寡（たか）」で変化し，外からだと確率論的に次の病態への推移が起こっているようにみえる。しかし，一つひとつの変化は実は確率論的に起こっているのではなく，膨大な数の因果関係の推移の組み合わせの結果によって引き起こされているのである。これを完全に観察して情報を収集できるだけの検査手段を持ち合わせていない現状でできることは，膨大な類似のケース（患者状態の推移のパターン）から学ぶことであろう。そうした発想から筆者らは東京大学生産技術研究所喜連川研究室の合田和生先生らとともに，複数大学病院の医療データを毎日，専用の高速検索のためのDBに取り込み，目の前の患者の病態パターンとマッチングをとって類似患者の病態推移を可視化するシステムの開発を目指している（図1）。
前述のようなシステムを実現するには，複数大学病院の医療データを統合して処理できるようなDBが構築される必要がある。そのためにはまず個々の病院の電子カルテに蓄積されている医療データを同一形式に標準化する必要がある。検査項目や検査材料種別などをそれぞれ識別する項目コードや材料コード，医薬品を識別する医薬品コード，投与量の単位，病名を識別する病名コードなどのコード体系が個々の病院で違っているので，それらを標準コードに変換したうえで一元化する必要がある。
また，各医療機関が使用している電子カルテシステム（医療DBシステム）はベンダー企業やシステムバージョンごとに異なるDB構造をとっているため，いったん何らかの共通データ形式に変換したあと一元化するのが効率的である。
このように多施設統合利用を前提に医療機関側の医療データを標準化，共通化する仕組みとして「SS-MIX2標準化ストレージ」規格が日本医療情報学会などにより策定され，2016年3月には厚生労働省標準規格に制定された2）。国内の医療情報システムのデータの二次利用や医療機関同士の情報連携において,各医療機関がこの形式にデータを変換してから利用することが推奨されている規格である。この規格は図2のように各医療機関で仕様の異なる電子カルテDBから，各識別コードを標準化し，かつデータ形式をISO IS 27931形式（HL7形式とも呼ばれる）に準拠したテキストデータ形式のファイルに変換し，階層的なディレクトリ構造（フォルダ階層構造）に格納したファイルストレージである。ディレクトリ階層はOSのファイルシステムに患者ID，診療日，データ種別の階層を順に構築したもので，特定の患者の特定の診療日の医療データを取り出す限りにおいては，ファイルシステムのディレクトリ階層をたどるだけでよい。
2015年3月の調査では，全国約7,400病院のうち48％に電子カルテか医療情報システムが導入されているが，その3分の1にSS-MIXが導入されているという結果が得られており，厚生労働省標準規格になったこともあり，今後ますます普及していくと考えられている情報システム基盤の一つである。
また，ここで用いられている主要な標準コードは，臨床検査項目分類コード（日本臨床検査医学会），JLAC10をベースにした臨床検査マスター，医薬品HOTコードマスター HOT9，標準病名マスターなどで，これらのコード表も厚生労働省標準規格となっている。詳細は参考文献3）のWebサイトを参照されたい。
医療DB構築の基盤を検討するうえで避けて通れない課題は，個人識別情報の匿名化である。医療DBは1件ずつが独立したデータレコードではなく，一人の患者の時系列のデータとして発生し蓄積される必要がある。一方で医療データは内容によっては非常に機微に触れる可能性のある情報であり，その人の知られたくない病歴情報や診察情報を含んでいる。たとえば，個人識別情報である氏名，住所，電話番号，病院における患者IDが削除されたデータとして，手術日，退院日，手術名と病名が記録されたデータがあるとしよう。匿名化されているから個人識別はできないと思われるかもしれないが，ある有名タレントがいつどこの病院で何の手術をしていつ退院したか，といった情報はメディアにより報道されていたり，本人やファンのブログに掲載されていたりすることは多い。そのため，手術日，退院日，手術名と病名がそれと一致すれば，その人と同定される確率は高いし，もし退院した病院が公開されていて匿名化情報にもデータソースの医療機関名あるいは所在市町村が含まれていれば，その確率はさらに高くなる。実際，米国のマサチューセッツ州が医療情報から氏名などを削除して公開した情報に対し，すでに公開されている他の情報と突き合わせることによって，州知事の医療情報だと特定した事例が参考文献4）（p.31参照）に紹介されている。この事例では，氏名を削除した医療データと，投票者名簿を照合した結果，州知事だと特定されたとされている。
一方で，研究など二次利用を考えると，一人の患者の時系列のデータが別々の人のデータとして解析されるのではなく，同一人のデータとして連結して解析される必要がある。以上のことから，二次利用のための医療DBでは，個人IDとして元の医療機関の全国レベル識別ID，その医療機関で発番された患者番号，文字列正規化という手法で漢字やカナの表記揺れを取り除いた氏名文字列，生年月日，性別符号などを連結して一方向性関数で変換したハッシュ値を生成して使用することが多い。氏名のうち姓の部分は結婚などで変化する可能性もあるので，これを含まず別の識別性のあるデータ要素，たとえば保険証番号情報を使ったもう一つのハッシュ値を求めてペアで格納するDBもある。たとえば，全国の医療機関から毎月の診療報酬請求のために提出されるレセプトデータを二次利用目的で国が全件収集しているナショナルレセプトDB（NDB）では，2つのハッシュ値を生成して格納している。しかし，結婚して被扶養者になると姓も保険証番号も変わるケースも多く，その場合には個人連結性は失われる。日本ではマイナンバー制度が導入されたが，マイナンバーは医療機関で患者を識別する番号としての使用は認められていない。そこでマイナンバーと1対1で発番されるが一般には連結ができない，いわゆる医療等番号（医療等分野の識別子（ID））の発行が厚生労働省の「医療等分野における番号制度の活用等に関する研究会」で検討，報告されており，これが使えるようになると医療等番号を含めたハッシュ値生成により，同一人連結性を確保できるようになるだろう。
ところで，たとえこのように個人識別情報をハッシュ値に変換するなどして匿名化しても，前述したように他の公知のデータと組み合わせることで個人同定できるリスクがある。医療データの場合には，手術名，病名，特殊性の高い治療名（臓器移植や全国で数か所でしか治療ができない治療など）とその日付データが含まれるとそのリスクが高まる。そこで日付を曖昧にすることや，特殊性の高い治療を含むデータの除外，k-匿名性（同じデータ値の組み合わせになるレコード件数がk個以上となるようにする匿名化手法）を確保するために病名や手術を少し粗めの分類コードに変換してしまうなどの処理も必要になる。たとえば，7国立大学病院を含む全国23病院の医療情報DBを統合解析することで，医薬品の副作用などを早期に検出するためにDBを構築するPMDA（独立行政法人 医薬品医療機器総合機構）のMID-NETデータベース事業では，データ抽出処理時に毎回1か月程度の範囲内でランダムに日付をずらす処理を行うなどして匿名化処理に工夫をしている。この事業のDB生成と抽出処理過程は，現在の医療DB統合処理における標準化と匿名化の課題を正面から取り扱った事業例として参考になると考えられるため図3にその概要を示す。
このシステムでは，医療機関の電子カルテDBから前述のSS-MIX2標準化ストレージに変換し，さらに匿名化後にリレーショナルDBに取り込み，DB利用者が作成した参加医療機関に共通のデータ抽出条件を記述した統計処理スクリプトを投入する。抽出結果は前述のように処理のたびに異なる再匿名化処理が行われ，その後に一次統計処理が実行される。この一次統計処理結果が各医療機関から統合データ処理センターに収集され，そこで多角的な分析が行われる。このように個票データと呼ばれる匿名化レコードは医療機関からは外に出ないで処理されるのが通常処理過程である。医療機関ごとの分散処理後に統合したのでは適切な解析ができない分析を行いたい場合に限り，個々の医療機関の個別承認を経て個票データ（前述の匿名化処理後データ）が直接収集される。
ここまで紹介してきたレセプトDBや副作用検出のための基盤DBは，日々の診療で発生する医療データを特定の病気に絞らず集積して大規模解析をする目的で構築されている。これとは少し性格を異にする医療DBとして臨床症例登録DB（患者登録DB：patient registry databaseともいう）がある。これは，特定の病気で特定の基準をみたす患者についてあらかじめ取り決めた医療データ種別を個々にDBに登録するもので，その病気に関する専門研究者が研究利用するために構築される。たとえば，国立国際医療研究センターが日本糖尿病学会と合同で進めている「診療録直結型全国糖尿病DB事業 （Japan Diabetes compREhensive database project based on an Advanced electronic Medical record System: J-DREAMS）」では，2015年度に29の医療機関が参加して，各医療機関の糖尿病診療医が診療している糖尿病患者のデータのうち，決められたデータ項目を登録する（図4，図5）。こうした臨床症例登録DBを学会や研究機関が構築する事業が増えており，他にも日本腎臓学会の慢性腎臓病DB（J-CKD-DB），日本救急医学会の救急領域統合DB，国立循環器病研究センターの日本脳卒中データバンクなどがある。
臨床症例登録DBでは各事業ごとにシステムを設計，開発することは非効率的であろう。そこで筆者はどのDB事業でも使える多目的臨床データ登録システムを開発し，MCDRS（Multi-purpose Clinical Data Repository System：マックドクターズ）と名付けて無償で提供している5）。MCDRSの特徴は施設内にSS-MIX2標準化ストレージが導入されていれば，そのデータをWeb上のデータ登録欄に自動転記できる機能を備えている点である。これにより症例登録時に臨床データ入力の手間が省ける。本システムは，前述した4つの臨床症例登録DB事業で利用されている。こうした共用できる医療DB基盤システムが複数開発，提供され，事業主体が目的や規模によって選択できるようになることが望ましいと考えている。
医療DBはこれからさらに種類もデータ件数も急増していくと予想される。多施設DBが複数の事業で構築されるようになると，同一患者の複数DBへの登録例が増えてくると考えられ，事業間でのDB連結による解析も重要になる。そのためには，患者の同意はもちろんであるが，事業間で同一データ項目の分類コードの共通化，標準化もさらに重要になるなど，今後の課題も多い。また，医療DBには医療機関で発生するデータだけでなく，これからはウエアラブル生体モニターにより得られる，生活圏や職場からの健康データが急増してくると考えられ，これらのデータは膨大だがノイズも多いという問題がある。さらに患者個人のゲノム情報も統合的に解析することが医療の新時代をもたらすことは確実である。本稿の最初の方で述べた病名一つをとっても，もはや臨床症状によって分類命名されてきた病名ではなく，ゲノム変異やタンパク質変異の違いなどの根本的な共通原因によって病気を分類し命名していく医学に急速に変わっていく。それに対応した新たな医療DBへの持続的変化が必要となる。そのためには，匿名化の課題だけでなく，こうした発生源の異なるビッグデータの統合解析において発生してくる種々の課題を解決していかなくてはならず，これを個別に解決するのではなく共通の基盤を整備していくことで効率化，質の高度化を図っていく必要があろう。
1984年東京大学医学部医学科卒。東大病院と新潟県佐渡で外科系研修などを経て，1986年より東京大学大学院博士課程で医用人工知能や医療情報システムの研究を行う。東大病院中央医療情報部（当時，現在企画情報運営部）で講師，助教授を経て1997年より東京大学大学院医学系研究科教授。医療情報の標準化や医療知識の計算機処理などに長年取り組んでいる。
