こんにちは、すきとほる疫学徒です。
医療大規模データベースを行う際に、
「沢山データベースがあるけど、どうやって選んだらいいの？」
「そもそもデータベース研究の実現可能性って、どうやって調べるの？」
という方に向けて書いております。
なお、こちらの記事は第二部になりますので、初見の方は必ずこちらの第一部からお読み頂くようお願いいたします。
こんにちは、すきとほる疫学徒です。 製薬企業で疫学研究をしておりますと、色々なところでデータベース事業者さんからお声をかけて頂くことがあるのですが、ここ数年でデータベース事業者さんや、事業者さんが扱う医療大規模データベース[…]
第一部でもお伝えいたしましたが、本記事は以下の国際薬剤疫学会が作成したガイドラインをベースに作成されております。
なお、この記事は第一部から第五部くらいまで続く予定のちょっとした大作となっておりますので、我慢してお付き合い頂けますと幸いです。
ちなみに、第一部では変数やサンプルサイズ、患者追跡期間など、医療大規模データベースの利用者サイドにフォーカスした項目がメインでした。
第二部以降は（そしてここがこのガイドラインの素晴らしいところなのですが）、データベースの結合、保存、データ抽出など、どちらかと言えばデータベースの構築者サイドにフォーカスした項目がメインになっていきます。
「私はデータ使うだけだから、読まなくていいや」と思われるかもしれませんが、個人的な意見としては「医療大規模データベースは、ブラックボックスなところが多いからこそ、どのように構築・運営されているかは利用者も知らねばならない」と思っております。
恥ずかしながら私も医療大規模データベース研究を始めたばかりの頃は、その構築の過程を知ろうともせず、「データ使い放題でラッキー、論文書きまくろう」と邪な気持ちを持っておりました（今も50％くらいは残っていますが。。。）。
しかし、何本か論文を書き、医療大規模データベースの知識もついてきた頃に気づきました。
「目の前にあるデータだけでなく、そのデータがどう集められ、保管され、抽出されたのかというところにもイマジネーションを持っておかないと、その詰めの甘さが研究デザインにも反映される」というところに。
例えば、とある医療機関から集めた診療報酬請求データを使って疾患の予測モデルを作っていた時です。
それまで私は、「病名って、診断されたらStart dateがついて、治ったらEnd dateがついて、そんで再発されたらまたStart dateがつくんだろう」と考え、予測モデルに投入する変数を検討していました。
しかしおかしなことに、盲腸や骨折など、長くとも数ヶ月あればフォローアップが終了するであろう疾患が、10年以上もactiveな状態として記録され続けているケースなんかもあったんですね。
そこで、「これなんだ？私の病名への理解、間違ってるのか？」と考えつきまして。
そうして日本の診療報酬請求データの入力プラクティスや、収集方法を隅々まで調べたところで、「診療報酬請求においては、一度Activeになった疾患は毎月のレセプトに掲載され続け、さらに医師が意図的にEnd dateを付与しない限りは、フォローアップが終わってもActiveな状態で残り続ける」ということを知りました。
他にも、データに意味不明な数字が入っていたり、以上にMissingが多い変数などもあり、それらもデータを集めた方に直接収集・保管プロセスをヒアリングしていくことで、「あーなるほど、ここでこういう収集・保管プロセスをとってるから、このタイミングで謎数字・Missingが出るんじゃないか」などと理解を進めることができた経験があります。
このように、医療大規模データベースを利活用する際には、背景にあるデータ構築・運営プロセスを意識せねば対処できないlimitation・biasなどもあるため、これらの知識は単に利活用だけをする方にとっても必須だと思います。
それに、個人的には医療大規模データベースを使った研究への貢献度というのは、構築・運営者95％：利活用者5％くらいだと思っているので、血の汗を流すような苦労をしてデータベースを構築・運営してくださっている方々へ敬意を払うという意味でも、ぜひ知っておくべき知識ではないでしょうか。
また、製薬企業で製造販売後調査を行う方にとっては、データベースの信頼性保証は重要なトピックであり（製造販売後調査で医療大規模データベースを使用する場合には、「このデータベース、こうやって集められて、クリーニングされて、保管されてるから、信用できるよ大丈夫だよ」ということを客観的に示す必要があるのです）、そのためにはデータベースの内容だけではなく、構築・運営方法をも十分に理解しておく必要がありますよね。
複数のデータソースの取り扱い ①Data resources containing different information on the same patients
単一のデータベースでは手に入る情報に限りがあっても、複数の外部データベースと結合することで、より広いリサーチクエスチョンに対応できる可能性が上がります。
例えば、NDBデータベースのような診療報酬請求データベースでは、基本的には診療報酬請求に記載された情報しか入手することができません。
それに対して、外部データソースである死亡届、出生届などを結合することができれば、より正確に患者の死亡・出産を定義することができます。
このように複数データソースをリンケージするためには、データソース間で同一患者に共通して振られるUnique IDが必要になります。
残念ながら日本ではこのような前データソース共通のUnique IDが存在していないため（マイナンバーがいずれその役割を果たすかもしれませんが）、データソース間のリンケージの難易度は非常に高いです。
ちなみに、医療大規模データベース研究が盛んな国として台湾があるのですが1、台湾では患者レベルのUnique IDであるPersonal identification numberを用いて、複数データソース間に結合が可能になっており、これは台湾でデータベース研究が盛んな理由の一つでしょう。
では、「Unique IDがないから日本では一切データソース間の結合ができないのか？」と言うと、そうではありません。
例えば、DPCデータベースでは病院名をUnique IDとして、医療施設調査や病床機能報告といった病院レベルのデータソースとの結合を行い、医師数や看護師数といった情報を入手可能です。これにより、交絡因子としてこれらの変数を調整することや、また曝露として用いることでStaffing研究が可能になっています。
また、データソース間の結合と言えば、日夜、医療大規模データベース研究の専門家が苦心しているのが、National Database (NDB)における名寄せ（linkage）の問題でしょう。
NDBは日本中の診療報酬請求で構成される日本最大の医療データベースですが、そんなNDBを活用する上での課題が「どのようにして複数施設から集まる同一患者のレセプトを結合するか」ということです。
患者ごとに振られるUnique IDがないため、研究者たちは保険者番号、生年月日、名前などを結合したLinkage algorithmを作成しました2。
現在主に使われるアルゴリズムには2タイプあるのですが、それぞれ”転職や就職で保険者番号が変わってしまう”、”結婚や離婚で名前が変わってしまう”などの課題があり、今のところ同一患者を複数データソース間で完全一致させるということはできていないのです。
2 野田ら. レセプト情報・特定健診等情報データベース（NDB）における患者突合（名寄せ）手法の改良と検証. 厚生の指標. 64, 12, 2017 Oct.
ですので、もしあなたのリサーチクエスチョンが”複数データソースを結合する必要がある”ものならば、
- どのようなAlgorithmで複数データソースを結合するのか
- そのAlgorithmの妥当性はどの程度であるか
ということはデータベース研究の実現可能性を調査する段階で調べておく必要があるでしょう。
最近、データベース事業者さんによってはRetrospectiveに集められた診療報酬請求データに、Prospectiveに集めたサーベイ結果を結合することで、診療報酬請求データ単体では知り得なかったデータを入手することが可能になってきています。
こういったデータベースを使用する際にも、「Linkageできるのね、便利だな」で終わるのではなく、必ず「Linkageはどのようなalgorithmでやっているのか？その妥当性はどうなのか？」ということはデータベース事業者さんに確認すべきだと思います。
複数のデータソースの取り扱い ②Data resources containing similar information on different patients
①とは状況が反転し、こちらは”含まれるデータは同じだが、異なる患者の情報をもつデータソースをLinkageする”ことについてです。
現在日本で使用可能な医療大規模データベースでは、こうした使い方ができるものは私の知る限りはありませんが、例えば病院や自治体レベルでデータを収集する際に、複数の病院、自治体に渡ってデータを収集し、データベースを構築していくということは頻繁に行われています。
どちらかというとデータベース利用者というより、構築者目線のお話かもしれませんね。
薬剤疫学において、こうした異なる患者情報を含むデータソース間のLinkageが必要になるのは、特に希少疾患を扱う場合でしょう。
日本全体でも数十例〜数百例しかいないような疾患の患者をコホートとして、比較研究を行うとなると、どうサンプルサイズを確保するかが問題になります。
その際に、データベースAでは足りないから、データベースBを結合するという選択肢が取り得れば、よりデータベース研究で対応できるリサーチクエスチョンの幅が広がりますね。
複数のデータソースの取り扱い ③Data storage
データストレージの方法は大きく分けて中央管理型と分散管理型の2種類あります。
中央管理型では、様々な施設から集められたデータを中央で一元管理し、その管理には中央のルールが適応されます（プライバシーやセキュリティに関するルール）。
一方の分散管理型では、データは各施設で管理されるため、管理には各施設のルールが適応されます。
私自身はこういったデータ収集・管理に関する作業をおこなった経験はないのですが、幾ら共通フォーマットがあると言えど、施設間でのデータ入力プラクティスには所々ばらつきがあるはずで、それを綺麗な一つのパッケージへと纏めあげるまでには膨大な労力が掛かっているはずです。
データベースの構築・運営をしてくださる先生方、本当にほんとうにありがとうございます。。。
複数のデータソースの取り扱い ④Data analysis
③で述べたように2種類あるデータストレージの方法に応じて、どうやってデータを解析するかというお話しです。
中央管理型の場合は、既に一元化されたデータがありますので、それをそのまま研究計画に則って解析していくだけですね。
分散管理型の場合は、これまた2種類の解析方法があります。
一つ目はIndependent analyticsで、こちらの長所は複数データに共通したデータ構造を設定する必要がないということです。まず、全施設に共通の研究計画が作成され、そしてそれぞれの施設のデータ管理者がその研究計画を各自のデータにアレンジする形で適応し、解析を行います。その後、各施設の解析結果を中央に集め、統合する、ないしはメタ解析が行われます。
二つ目は、Coordinated or distributed analyticsで、こちらではまず複数データに共通したデータ構造を設定します。そして、各施設から集められたデータを中央の管理者が共通のデータ構造へと変換し、解析するわけですね。
終わりに
さて、今日は少し短めでしたが、データベースの構築段階におけるお話をさせて頂きました。
次回の第三章は、Data extractionということで、構築された医療大規模データベースから、どうやって自分の研究に必要なだけのデータを抽出してくるのかということをお話ししていきたいと思います。
こんにちは、すきとほる疫学徒です。 医療大規模データベースを行う際に、 「沢山データベースがあるけど、どうやって選んだらいいの？」 「そもそもデータベース研究の実現可能性って、どうやって調べるの？」 […]
すきとほる疫学徒からのお願い
本ブログは、読者の方が自由に記事の金額を決められるPay What You Want方式を採用しています。
「勉強になった！」、「次も読みたい！」と本ブログに価値を感じてくださった場合は、以下のボタンをクリックし、ご自身が感じた価値に見合うだけの寄付を頂戴できますと幸いです。
もちろん価値を感じなかった方、また学生さんなど金銭的に厳しい状況にある方からのご寄付は不要です。
引き続き情報発信していく活力になりますので、ぜひお気持ちに反しない範囲でご寄付をお願い致します！
