医療系リアルワールドデータを扱う上での3つの課題

リアルワールドデータを扱う上では、多くの課題があると言われています。

私はこの分野を専門としていますが、課題としては

データコンテンツ，

データ構造，

大容量データの処理

の三つだけです。

色々と言われていますが、今のところ、すべてこのカテゴリーの中に当てはまります。
それぞれについて説明します。

課題 1：データコンテンツ

データベース研究では，研究に必要なコンテンツがデータベースに格納されていないケースが少なくない．データ収集時の問題で物理的には補う。各テーブルの情報を凝縮追加データ構造変換追加・整形抽出データデータベース データウェアハウスことができないデータもあるが，可能な限りデータ解析時に不足するデータを補うことが望ましい．本稿ではこのような課題をデータコンテンツに関する課題と呼ぶ．この課題は，データの特性から下記の二つに分類することができる．

① 外部データにより補完するコンテンツ
② データ整形や計算により補完するコンテンツ

上記 ① は，データベース内に物理的に存在しないコンテンツを指す．代表例としては，医薬品，検体検査，傷病名，特定器材等のマスターデータ（医薬品，臨床検査コード等の付随情報等）が挙げられる．

これらのマスターデータは必要に応じて外部から入手し，データベース内のテーブルに紐付ける必要がある．次に，上記 ② は，データベース内のデータや追加済の外部データを基にデータ整形や演算により補うためのコンテンツを指す．例えば，臨床研究や薬剤疫学分野の研究では，医薬品の処方量，予後に関す特定の医薬品に関する処方量（mg，mL 等），単剤・多剤投与の有無，抗菌薬の有無，医薬品の連続投与日数などの変数が頻用される．これらの変数が解析対象のデータベースにあらかじめ含まれており，かつ解析に適した形式になっていれば問題ないが，多くの場合処方日，医薬品の処方状況等を用いてデータ整形等の作業を行う必要がある．また，終末期医療に関する研究で頻用される，Charlson ComorbidityIndex Score（CCI）は重篤な傷病の併存状況をあらわした疫学指標として知られているが，これもICD コード等で傷病名を分析することで演算により ス コ ア を 算 出 す る こ と が で き る 良 い 例 で ある．さらに，厚生労働省が管理しているレセプトデータベースに格納されている患者 ID の信頼性を高める研究もバリデーション研究の一環としてなされており，このような事例もデータコンテンツを改善するための取り組みに含まれる．以上のように，外部データやデータ整形等の計算で補う変数は多種多様であるが，データベース内の変数（病名，患者 ID 等）を補うという観点からは共通しているため，本稿では同一のカテゴリーに集約した．

課題 2：データ構造

医療情報系データベースは，そのほとんどがリレーショナルモデル（脚注 3）） をサポートするリレ ー シ ョ ナ ル デ ー タ ベ ー ス（Relational Data -base：RDB）で運用されている．RDB のテーブル設計においては，テーブルの更新時（挿入・削除・修正）異状を解消するために，事象ごとに別個のテーブルに格納する正規化を実施することが一般的である．正規化にはいくつかの段階があり，一般的な RDB では，第三正規形と呼ばれる形式まで正規化していることが多い．結果的に，患者に関する情報が傷病名，医薬品，診療行為等の事象ごとに複数のテーブルに分散して格納される．このようなデータ構造は，全国の医療機関の電子カルテやレセプトを格納しているデータベースのみならず，レセプトデータベースとして知られる台湾の NHIRD や韓国の HIRA，米国の 臨 床 研 究 用 の デ ー タ モ デ ル と し て 有 名 なOMOP Common Data Model，FDA が先導している電子カルテとレセプトを中心とした臨床研究用のデータベースであるセンチネルに採用されている Sentinel Common Data Model等の世界的に医学研究に利用されているシステムにおいても共通している．このように，ほとんどの医療情報系データベースは，患者に関する情報が複数テーブルに分散している．このため，患者ごとに研究に必要なイベントが整理されたデータセットを作成する際には，プログラミング言語や SQL（脚注 3）） を用いたデータ整形が必要となる．

課題 3：大容量データの処理

RWD は，診療や検診，調査等によりデータが日々蓄積されていくという特性から，データ容量が極めて大きくなる傾向にあり，いわゆるビッグデータの特性を備えている．どの程度のデータ規模からビッグデータであると言えるのかに関し
ては明確な定義はないが，1 台のコンピュータでは，テーブル単体のデータサイズが 100 ギガバイトに達する近辺が目安であると言われている．特に，電子カルテやレセプト等の大規模化する傾向が強いデータベースでは，各テーブルのレコード数が数百億件以上に及ぶ場合もある．このような場合，蓄積されたデータに対して比較的複雑な処 理 を 実 施 す る と 相 当 の 処 理 時 間 が 必 要 と なる．特に，プログラミング言語や統計解析用のソフトウェア（R，Stata，SAS 等）を用いた場合には，ストレージ（HDD や SSD）に対するデータ書き込み，読み込みが大量に発生するため，膨大な処理時間が必要となる．場合によっては，データを分割して扱うような工夫をせざるを得ないこともある．表形式のデータ処理に特化しているプログラミング言語 Python の Pandas ライブラリや統計解析ソフトウェア R の dplyr パッケージを用いたとしても同様の課題が残る．原理的に CPU からストレージへのアクセス速度はCPU からメインメモリへのそれと比べて速度が随分と劣るためである．扱うデータ量を上回る容量のメインメモリを計算機に搭載することでこの課題は概ね解決することができる．ただし，現時点で電子カルテやレセプト系統のデータベースのデータ量は数テラバイト級に達しており，すべてのケースに通用する現実的な対策とはいえない．一般に，独自のデータバッファリング機能やデータ管理を効率化する仕組みが実装されており，ストレージへの読み書き回数を低減できるリレーショナルデータベースを用いるのが効率的である．
以上で述べた課題を踏まえると，データベース研究における前処理は，「既存のデータベースに対して個別の研究に必要なコンテンツを補完した後に，1 患者 1 レコードのデータ構造になるように変換すること」と再定義することができる．さらに，所望の研究で大容量データを扱う場合には，コンテンツ補完とデータ構造変換の過程において処理時間が大幅に増えることとなり，データ前処理作業の負荷は極めて高くなる．現場レベルにおいても，医療機関の電子カルテデータベースを用いた臨床研究目的の抽出作業は医療情報の専門家が支援しているという事例や，データハンドリングに不慣れな研究者がデータベース研究を実施したところ，比較的簡易な研究デザインであったにもかかわらず研究完了までに数カ月を要したという報告もある．

このように，データの前処理作業は，データベース研究において最も負荷が高い工程であることが世界的に認識されてい
る．このような背景から，米国ではレセプトデータベースを用いた研究において疫学や情報学等各分野の専門家を配置し，研究実施者のサポートを手厚く行う体制を整えている．我が国においても，データベース研究は，各領域の専門家が協力して実施することが望ましいという意見が多いが，消化器癌に関するレセプトを用いた研究においては，十分な情報処理技術を備えた医療情報の専門家が取り組んだにもかかわらず，コンテンツ補完の課題に加えて大規模データであったため，データセット作成までに実質的に 1 カ月以上を要することになり，データ前処理の負荷が極めて大きかったと聞いている。