ホーム> 政策について> 審議会・研究会等> 保険局が実施する検討会等> レセプト情報等の提供に関する有識者会議> 第32回レセプト情報等の提供に関する有識者会議 議事録(2016年7月27日)




2016年7月27日 第32回レセプト情報等の提供に関する有識者会議 議事録

○日時

平成28年7月27日(水)10:00~12:00


○場所

全国都市会館3階 第2会議室
(東京都千代田区平河町2-4-2)


○議題

1.オンサイトリサーチセンターについて
2.民間提供について
3.その他

○議事

○山本座長 皆様、おはようございます。定刻より少し前ですけれども、出席予定の構成員の方は全員おそろいですので、ただいまから第32回「レセプト情報等の提供に関する有識者会議」を開催させていただきます。

 構成員の皆様には、御多忙の折、お集まりいただき、厚く御礼を申し上げます。

 会議に先立ちまして、本日の構成員の出欠状況について、事務局からお願いをいたします。

○赤羽根室長 おはようございます。事務局でございます。

 それでは、本日の構成員の出欠状況について御報告させていただきます。本日は、伊奈川構成員、猪口構成員、印南構成員、府川構成員、松田構成員、三浦構成員、武藤構成員、それから、座席表に名前はございますが、宮島構成員から欠席の御連絡をいただいております。また、棟重構成員も御欠席でございまして、構成員の代理として健康保険組合連合会IT推進部長の樋口参考人に御出席いただいております。9名が本日御欠席ということで、ぎりぎり会議の規程に基づいた開催要件は満たしております。

 本日は、議題1の議論に際しまして、参考人として出席いただく先生方がいらっしゃいますので御紹介させていただきます。4名でございます。

 京都大学医学部附属病院診療報酬センター、加藤源太准教授でございます。

 京都大学大学院医学研究科社会健康医学系専攻健康情報学分野、酒井未知特定研究員でございます。

 京都大学大学院医学研究科社会健康医学系専攻健康情報学分野、大寺祥佑特定研究員でございます。

 京都大学医学部附属病院医療情報企画部、岩尾友秀特定研究員でございます。

 事務局からは以上でございます。

○山本座長 ありがとうございます。

 開催要件を満たしているということですので、早速ですが、議事に入りたいと思います。

 本日の議題の1つ目「オンサイトリサーチセンターについて」、前回、東京大学のオンサイトリサーチセンターから御報告いただいたところですけれども、今回は京都大学からということで、よろしくお願いをいたします。

○加藤参考人 京都大学の加藤でございます。本日はこのような機会をいただき大変ありがとうございます。

 昨年の3月に、この有識者会議の場におきまして、オンサイトリサーチセンターでの模擬申し出の承諾をいただきました。その後、各方面で準備を重ねまして、東京大学、厚生労働省の皆様方とも連携をしながら、データ利用のパフォーマンステストを中心に、オンサイトリサーチセンターの機能、それから研究者目線でどういったことが研究できるのか、あるいはどういったことが分析可能なのか、そういったことをさまざまな方面から検証してまいりました。本日までに一定の検証を行って、成果をお示しできる状況になりましたので、皆様方の前で御説明させていただきたいと思います。どうぞよろしくお願いいたします。

 それでは、各研究員より、オンサイトリサーチセンターでこれまで行ってきましたパフォーマンステストの概要を説明させていただきたいと思います。

○酒井参考人 京都大学の酒井と申します。私は、京都大学で疫学を専攻した後に、疫学研究のデータマネジメントと統計解析、地域医療計画の策定支援業務を行いまして、現在に至ります。

 それでは、資料1「レセプト情報等オンサイトリサーチセンター(京都)パフォーマンステスト結果報告」について御説明させていただきます。

 資料2枚目、初めに、試行的利用開始後の模擬申し出実施状況について簡単に御報告致します。

 京都大学では、2月17日にオンサイトリサーチセンター(京都)運用部を設置し、試行的利用を開始いたしました。3月の有識者会議では、教育プログラム、公開演習環境等の整備を提案いたしました。5月以降は実務者会議を定期的に開き、東京大学と情報共有をしながらパフォーマンステストを進めまして、件数集計、統計解析を行ってまいりました。

 資料の3枚目でございます。オンサイトリサーチセンターのデータ抽出・分析アプリケーションの概要をお示ししております。オンサイトリサーチセンターには、大きく分けて、データ抽出・件数集計を行うツールと、統計解析を行うツールがございます。定型帳票と自由分析は、マウス操作でデータの分析を行います。そのほかのツールは、コマンド、操作する内容をテキストで打ち込む形でデータ分析を実行するツールでございます。

 定型帳票は、プルダウンのメニューから検索するメニューを選択しまして、レセプトの行単位を数える定型的な分析を行うことができるツールです。

 これ以外のツールは、利用者がテーブルや列、レセプトデータを分析する単位を自由に選択して、非定型的な分析を行うツールでございます。

 最後の分け方としては、サーバー、NDBのデータセンターの中でデータ解析を行うツールか、あるいはサーバーにあるデータを自分のパソコン、ローカルの中に引っ張ってきて解析を行うツールかといった違いがございます。

 続きまして、資料の4枚目、それぞれのツールの画面をお示ししております。

 4枚目、定型帳票は、プルダウンの検索メニューから分析対象のレセプトの条件を指定して、件数集計や作図を行うツールでございます。

 5枚目、自由分析は、マウス操作でデータを抽出するテーブルや分析する対象の列などをドラック・アンド・ドロップする形で選択して、件数集計や作図を行うツールでございます。

 6枚目にありますSQL Plusは、SQLというテキストの構文で分析対象のレセプトの条件、集計方法を指定する内容を入力して、件数集計を行うツールでございます。

 続きまして、統計ソフト、RとSASの画面をお示ししております。こちらも同じように分析する対象のレセプトの条件、解析方法をテキストで入力して、統計結果を表示させるツールでございます。

 8枚目、今回の京都大学のパフォーマンステストで検証した事項は、レセプト・患者の件数集計、ローカルでのデータ解析、サーバーでのデータ解析の3つのパフォーマンスについて検証いたしました。2番のサーバーとローカルのデータ解析は、サーバー、データセンターの中でデータの作成や分析を完了させた場合、サーバーにあるデータをローカルに引っ張ってきて解析を行った場合の比較でございます。

9枚目、パフォーマンステストの全体像を検証事項と検証に用いたツールの対応表としてお示ししております。今回、テスト1~5を行いまして、それぞれのテストで同じ作業を違うアプリケーションで実行して、抽出されたデータの件数、実行にかかった時間、操作感を比較いたしました。

10枚目、集計・解析対象レセプトの条件を記載しております。

 テスト1、レセプト件数の集計では、前立腺がんまたは前立腺肥大症の病名の医科レセプト1年分。

 テスト2、患者数の集計では、高血圧を含む医科レセプト6年分の患者件数を集計いたしました。

 テスト3~5のデータダウンロードと統計解析では、高血圧症性疾患のDPCレセプト2年分を集計対象といたしました。

 続きまして、11枚目、これ以降がパフォーマンステストの結果報告となります。

 テスト1、レセプト件数集計テストでは、前立腺がんまたは前立腺肥大症患者の1年分の医科レセプトを集計した結果をお示ししております。この表の中で定型帳票の抽出数のみ、レセプトの行数の結果、約3,496万行となっております。このレセプトの行数と申しますのは、1件のレセプトの中に前立腺がんと前立腺肥大症の2つの病名が含まれていた場合、レセプトの件数は1件、行数は2行となりますので、定型帳表では抽出件数がふえております。

 自由分析とSQL PlusOracle Rでは、レセプト件数の集計が一定時間内に可能でした。ただし、実行時間2にお示ししておりますレセプトの取り込み作業中、データセンターの中で月初めに新しいレセプトを取り込む作業を行っている場合は、実行時間が長くなる傾向がございました。

12枚目、患者数集計テストでは、高血圧症の医科レセプトの患者数を集計しております。平成2227年の6年分の集計結果では、 Oracle R39分、自由分析では24分、SQL Plusでは17分で6年分の患者数の集計が可能でした。SQL Plusに関しては、オンサイトにあるPCを2台で同時に同じ集計を実行した場合の検証、抽出する件数を1年分から6年分に順次ふやした検証も行っておりまして、抽出の件数、PC台数、いずれをふやしても実行時間が線形的に増加する傾向がございました。

13枚目、今回のテスト1と2の結論、高負荷のレセプト件数集計、患者件数集計が、自由分析、SQL PlusOracle Rで一定時間内に可能でした。

14枚目、テスト3は、高血圧症性疾患の4年分のDPCレセプトをローカルにダウンロードするテストを行いました。データの作成とダウンロードの実行にかかった時間をSQL PlusOracle Rで比べますと、SQL Plusでは約8時間、Oracle Rでは25分という結果でございました。

SQL Plusに関して、データのダウンロードをしないでデータの作成だけを行った場合には5分で結果が出ました。データの作成とダウンロードに加えて、ダウンロードしたデータを全行パソコンに画面表示させる処理を追加しましたところ、SQL Plusで約86時間要しました。

15枚目に結論がございます。今回のテストの結論は、データのダウンロードは、Rのほうが実用性が高い。SQL Plusは件数がふえると長時間かかる可能性がございます。

 次に、テスト4、ローカルで統計ソフトSASを用いて高血圧症性疾患の2年分のDPCレセプトを解析した結果を16枚目にお示ししております。単回帰分析と重回帰分析がいずれも1分以内で完了し、ローカルでSASを用いた解析は一定時間内に可能である。

 続きまして、ローカルでRを用いて高血圧の2年分のDPCレセプトを解析した結果が17枚目にございます。年齢層別のレセプト数の作図、単回帰分析、重回帰分析を実行しましたところ、エラーメッセージが出まして、処理を続けることができなくなりました。

 テスト4から、ビッグデータをローカルでRを用いて解析すると、何らかの制限があるのではないかということが考えられましたので、次の18枚目、同じデータをサーバー内で解析した場合を比べたのがテスト5でございます。

18枚目のグラフは、高血圧の2年分のDPCレセプトを、ローカルでRを用いて解析した場合と、サーバー内でOracle Rを用いて解析した結果の違いをお示ししております。ローカルでRを用いて解析した場合は、データ読み込み、サンプル作成、単回帰分析、重回帰分析の処理を実行した段階でメモリの上限16ギガに達し、続行できなくなりました。

 メモリについて補足させていただきますと、パソコンの中にあるデータを分析するための作業スペースみたいなもので、広ければ広いほど大規模データを効率よく処理できますが、スペースの広さを超えた大きなデータを置いてしまうと、それ以上作業ができなくなるといったイメージでございます。

 一方、Oracle Rは、いずれも重回帰分析まで数分で実行可能でした。

19枚目、テストの結論は、ローカルで統計解析を行う場合には、Rはメモリによる制約が大きい。

 現状、大規模データ解析は、SASによるローカルでの解析、またはOracle Rによるサーバーでの解析が、実用性が高いのではないかという結論を得ました。

20枚目にオンサイトの大規模データ解析のパフォーマンスを一覧にしております。レセプト数、患者数の件数集計は、自由分析、SQL PlusOracle Rでできる。データのダウンロードは、Oracle Rでできるが、SQL Plusで行う場合には長時間かかる可能性がある。そして統計解析は、ローカルでSASを用いた解析あるいはサーバー内でOracle Rを用いた解析が実用性が高いのではないかと考えられます。

 結語でございます。今回、オンサイトリサーチセンター(京都)のアプリケーションを試行的に利用しまして、データ抽出、件数集計、統計解析のパフォーマンスを検証いたしました。今後は、模擬申し出の課題に即して、引き続き検証を行ってまいる予定でございます。

 以上でございます。

○加藤参考人 ありがとうございます。

 以上が私どものパフォーマンステストの結果の概要となります。オンサイトリサーチセンターに実装されているアプリケーションには様々ありますが、いわゆる研究課題、具体的かつシンプルな例として、例えば高血圧の患者さんの数はどうなのか、あるいは前立腺の疾患の患者さんの数はどうなのかという事例を想定し、集計にの程度時間を要したか、その他の分析にどの程度のことが出来たかというのをこちらにお示しさせていただいた次第でございます。

 続きまして、酒井とともにデータ分析を行った大寺、岩尾の二人からは、オンサイトリサーチセンターでの検証作業を経る中で感じたこと、例えばこういったことがあればもう少し研究が進むのではないか、あるいはこういったところは非常にやりやすかった、等々を、率直な操作感や使用感とともに説明させていただきます。

 

○大寺参考人 京都大学大学院医学研究科の大寺と申します。よろしくお願いいたします。

 このたび幸いにも操作者の一人としてパフォーマンステストに参加させていただく機会を得ました。この経験を通じて感じたことを簡潔に述べさせていただきたいと思います。資料は用意しておりませんので、あらかじめ御了承ください。

 私のバックグラウンドは、こちらの酒井と同様、臨床疫学です。本年の2月に京大の研究員として着任するまでは、臨床現場、医療機関でクオリティ・インディケータを用いた医療の質の評価などを行っておりました。単体の病院のDPCデータを分析した経験はありましたが、全国規模の医科レセプト等を含むNDBを扱うのは、今回のパフォーマンステストが初めてのことでした。DPCは比較的分析しやすく整備されているデータであるのに対して、医科レセプトにはICD10のコードや退院日などのデータが含まれておりません。このようなデータの構造の違いにまず私はテスト開始当初、戸惑いを感じました。

 また、前職で経験しておりましたRやSPSSといった統計ソフト、こちらに関しては多少慣れていました。ただ、分析用のデータ抽出に関しましては、その当時は情報部門のエンジニアに全て任せておりましたので、自分の手でSQLというデータベースを扱うコンピューター言語を使って大規模データベースをハンドリングしたことは、それまでありませんでした。

SQLに関しては、このパフォーマンステストが始まって半年間で自習をしまして、ある程度知識やスキルに関しては身についたと感じております。ただ、複雑な処理が必要なときに関しましては、こちらにおります情報学分野出身の岩尾が適宜サポートしてくれました。

 このような各自の専門性を生かしたチーム、こういうチームづくりが今回のパフォーマンステストを可能にしたのではないかと考えています。

 オンサイトリサーチセンターを効果的に利用するには、NDBデータの構造、臨床や政策現場の知見、統計解析、コンピューターサイエンスなどのさまざまな知識やスキルが必要とされるということが今回のテストを通じてわかりました。これら全てを一人の人間がカバーするというのは、正直に申しまして、現実的にかなり困難だと考えております。今後の第三者公開に当たっては、利用者を多方面から適宜サポートできる環境づくりが必要なのではないかと感じた次第です。

 私からは以上です。御清聴ありがとうございました。

○岩尾参考人 京都大学の岩尾と申します。よろしくお願いいたします。

 このたびオンサイトリサーチセンターでパフォーマンステストに携わらせていただきました、その感想を述べさせていただきたいと思います。

 私自身はもともと情報工学の出身でして、現在は医療情報学を専門としております。前職は、臨床試験のデータマネジャーをやっておりました。そのために完全なデータベース分野の専門家ではないのですが、民間でエンジニアをしておりましたので、そのような経験から、コンピューターの中でデータがどのように処理されているか等については常に意識しておりますので、今回のオンサイトのデータベースを初めとした最先端の環境に携わらせていただくことができて、非常に興味深い体験をさせていただきました。

 当初は、レセプトや疫学に関する知識もほとんど有していなくて戸惑うことも多かったのですけれども、その折に、ことしの2月から、本日発表していただいた京都大学のお二人の研究員の方がパフォーマンステストに参画していただけることになりまして、このことによって大きく状況が変わって進展したと思っております。我々だけでパフォーマンステストをやっていたのではなくて、少し解決が困難な課題に直面した際には、京都大学の加藤先生ですとか、データベースの専門家である黒田先生、岡本先生等、そのような方々のお力をかりながら実施することで、このような成果が出せたのではないかと思っております。

 今回のパフォーマンステストを通じて、オンサイトでは、やはり多くの分野の知識が必要であることを実感しました。正直申しまして、オンサイトのパフォーマンステストというのは私一人ではとてもなし遂げることは困難であったと思っております。ですので、今後オンサイトを利用される先生方に関しては、オンサイト特有の操作環境になれるまで、なかなか作業効率を高めることは難しいと思います。ですから、今後もオンサイトを利用される研究者の方々によりよい環境となるように、引き続き検討をさせていただきたいと考えております。

 以上です。ありがとうございました。

○加藤参考人 私どもからの発表は以上となります。御意見等をいただければ幸いでございます。どうもありがとうございます。

○山本座長 どうもありがとうございました。

 それでは、今までの御説明に関しまして、御質問、御意見がありましたら、どうぞよろしくお願いいたします。

 どうぞ。

○大久保構成員 成果についての御発表ありがとうございました。

 素人的で申しわけないのですが、11ページのSQL Plusを使った場合、普通だと12分ですけれども、センターで作業していると4時間27分かかるという物すごい差が出たわけです。一方、18ページのRとOracleを使った重回帰分析で、Oracleの場合は5分で終わりますけれども、これはセンターのほうで作業していたときに、この5分というのは何らかの影響を受けて1時間になるとか、そういうことは考えなくてよろしいのでしょうか。

○加藤参考人 御質問ありがとうございます。

 私どもも、今ではこのように検証できた事項を整理して、これこれこういう結果だったということをご説明させていただけるのですが、最初の時点では当然、ひとつの集計作業に何分かかるかわからない、入ってみなければわからない、エンターキーを押してみなければわからないという状況でやらせていただきました。ひとつ例を押しますと、この5月に集計をした際には一つの作業に何十時間も要したことがありました。大変驚いたのですが、後で厚生労働省、それからデータセンターに問い合わせたところ、月のうち1日あるかないかの一番混雑していた時間帯だと聞いています。

 今の大久保先生の御質問の答えになるかどうかわからないですが、どんな解析をする場合にも、先の例のような月に1日あるかないかの繁忙日には影響を受けると思います。ただ、私共もそういった経験を踏まえて、その後の連絡協議会で議論し、データセンターが非常に忙しい日についてはあらかじめ情報共有してその時期には作業を入れないようにする、という取り決めを行い、事態は改善しました。今後、第三者提供を考えるのであれば、こういったことにも対応していく必要があるなと感じました。

○山本座長 ありがとうございます。

 ほかはいかがですか。

 どうぞ。

○頭金構成員 実際の作業についてお伺いしたいのですけれども、ここに示されている患者数というのは名寄せを行っているのでしょうか。それとも、延べ数で表現しているのでしょうか。

○酒井参考人 重複しない患者IDの数を数えておりますので、今の御質問のお答えは、名寄せをしているというのが御回答でございます。

○頭金構成員 一応、名寄せの作業もこの時間内におさまっているということですね。

○酒井参考人 はい。全てこの時間内に、データセットから重複のない患者IDの数を数えるまでの、スタートから集計が終わるまでの時間をお示ししております。

○頭金構成員 わかりました。ありがとうございます。

○山本座長 ほかにいかがでしょうか。

 どうぞ。

○石川構成員 どうもありがとうございました。

 ちょっとお聞きしたいのは、実は東大のオンサイトセンターにこの間、見学に行かせてもらったのですけれども、東大と京大との違いみたいなものは、センターの内容の違いだとかそういったものはあるのか。それから、使われているソフトは違うのかとか、そういうことについて教えていただきたいということです。

 それから、今こうやって私も東大のほうを見せていただいたり、皆さんの発表を聞いたりして、今後、公衆衛生だとかそういったものをやる方たちは、例えばSQLプログラムの話をどのぐらいできるのか。必要があるのか。今後はそういうものまで養成の中で入れなければいけないのかということについて教えてください。

○加藤参考人 御質問ありがとうございます。

 まず私のほうから御質問にお答えさせていただきたいと思います。

 最初にありました東大と京大の違いについてということですが、私が聞いている範囲では全くありません。同じ環境が用意されている。その同じ環境で、当初東大と京大が例えば同じ作業を同じ時間に全部のPCから一斉に負荷をかけたらどうなるか、といった検証も当初想定していたのですが、先の例のような繁忙日だと、単純集計のような作業でも数十時間かかるということになったので、限られた時間でそれをやるのは少し現実的ではないと判断し、検証した結果は適宜東大と京大と意見交換しながら進めてまいりました。

 厚生労働科学研究の戦略研究においてもこうした事業を行うこととなっていましたので、本日発表の機会をいただいた酒井、大寺、岩尾の3人のメンバーは、特に単純集計の評価、それから件数の評価だとか、アプリケーションごとの比較だとか、パフォーマンステストという課題に注力して対応させていただきました。京大としては、ユーザーに対してどういう機能が用意されているかということを、今回のパフォーマンステストで具体的にお示ししたいと思って準備させていただいた次第です。

 2つ目の御質問についてですが、私どもの印象では、例えば医療情報に詳しい、医療統計に詳しいという人がいたとしても、それが現在のレセプト情報等オンサイトリサーチセンターが備えている機能を適切に使える能力に直結するかと言えば、必ずしもそうとは言い切れないと考えています。SQLに対するリテラシーは、印象としては、利用者には備えておいていただかないとちょっと困るかなと思います。酒井より説明のありましたプルダウンで操作できるアプリケーションも、確かに用意されてはおりますが、そのアプリケーションの機能が研究者のニーズを満たすものかどうかというのは、保証の限りではないと思っております。ですので、このレベルのニーズだったら、ユーザーにはこのぐらいの能力があればいいです、しかしそのレベルの分析をやろうとする人であれば、こういう能力は必ず備えてから臨んでください、でないといたずらに時間を消費してしまいますよ、といったことの情報提供は、今後積極的にすすめていかなければいけないと考えています。

○山本座長 ありがとうございます。

 ほかはいかがでしょうか。

 どうぞ。

○大久保構成員 11ページは単純集計での時間が出ていますが、通常研究する上でこれに性、年齢、住所、病院、例えばそういうクロスをかけていくと、当然時間がさらにかかってくるのか、それはほとんど影響ないのかというのは、どんな感じなのでしょうか。

○岩尾参考人 お答えいたしますと、確かに少々時間はかかるかもしれないのですけれども、その加える性別であるとか住所の表も一つのテーブルの中におさまっておりますので、さほど影響は、それほど劇的におそくなるということはないと考えております。

○山本座長 ほかにいかがでしょうか。

 どうぞ、石川さん。

○石川構成員 先ほどのSQLプログラムの話なのですけれども、東大のところで見学させていただいたときもちょっと言ったのですが、私たちも実は日本医師会のところで研究所がありますので、研究所の者たちがそれらの全て能力があるわけではないので、別にそういう人材を投入して、医学研究だとかそういうものをやらなければいけないかどうかということに、私たちの立場としてもそのようになるわけです。

 希望としましては、先生方が京大でも、東大でも、単純に共通で使えるようなスケールプログラムみたいなものをデフォルトで残しておいていただいて、研究者が非常に標準的な使い方をするときにはそういうものが使えるとか、ちょっと書きかえればいいとか、そういう蓄積を2つのセンターでやっていただくのが、今後日本でこれが使えるというようなことになるのではないかと思うのです。

 もう一つ、私は先ほどから、今後こういうデータを私たちが使うなどということはもうあり得ないので、皆さん、若い先生方がどうやって使うのかといったときの後継者づくりというところで聞いているわけなのですけれども、酒井先生のお話の中に、レセプトの限界といいますか、データの特質みたいなものについて、要するに十分知らなければいけない。それから、DPCのデータについて知らなければいけない。それから、MID-NETというものが世の中にまたありますから、そういうビッグデータの違いみたいなことについてきちんと後に残るように研究者の方たちにはやっていただきたいというのが希望です。

 例えば先ほど前立腺がんと前立腺肥大のことがありましたけれども、あれが2行なのか1行なのか。実は前立腺がんというのは基本的には前立腺肥大の中から出てくるので、要するに、それはレセプトを書いた者が単に分けただけの話なのです。だから、そこら辺のところですね。そのようなレセプトの性質だとか、そういったものについても一定、先進的な方たちは知識として残しておいていただけるようにお願いしたいと思います。

○山本座長 ありがとうございます。

 ほかはいかがでしょうか。

 どうぞ。

○頭金構成員 先ほど東大との比較という御質問もあったのですけれども、今回のパフォーマンステストの結果をまとめると、データのダウンロードをOracle Rでやって、解析をローカルでやれば一番パフォーマンスが高いというような結果になると理解しました。この結論は一般化していいものかどうかということについて、御意見をお伺いしたいと思います。

○大寺参考人 データのダウンロードに関しては、今回の検証の結果どおり、恐らくOracle Rが一番いいという結果は一般化してもよいのではないかと考えております。ただ、統計解析に関しましては、Oracle Rというサーバー上での統計解析に関する今回のパフォーマンステストの結果で、大規模なデータを使ってかなりの負荷があるデータ分析でも十分に行えたというところもあります。

SASに関しては、ローカルでの分析になります。ローカルのRの分析では、メモリがいっぱいになってしまうという現象がありました。SASのほうでどの程度まで耐え得るかというところは、今のところ未検証の部分もありますが、統計解析に関しては、ローカルのSASOracle Rというサーバー上で行う解析、どちらかを使うというのが有力なツールになってくるのではないかと考えております。

○山本座長 ほかにいかがですか。よろしいですか。

 私のほうから少し質問させていただきたいのですけれども、SQL PlusOracle Rでダウンロード時間が違うというのは、このダウンロードの意味は、処理が終わってダウンロードに入ってということですか。つまり、OracleのネイティブのSQLSQL Plusの速度の違いですか。

○岩尾参考人 こちらはSQL Plusというツールと、あとOracle Rというソフトウエアの性能の違いであると思っております。ソフトウエアの中でどのようにしてダウンロードしているかというのは実装がソフトウエアによって異なってくると思いますので、そのあたりの。

○山本座長 結果のファイルサイズは一緒ですね。

○岩尾参考人 同じです。

○山本座長 字義どおりのダウンロードだと、その状態でネットワークのスピードが急激に変わることがなければ大体同じだと思うので、要するに処理時間の違いですね。

○岩尾参考人 そうですね。

○山本座長 SQL PlusOracleのネイティブのSQLの違いということですかね。

 それからもう一つ、14ページの表で、SQL Plusで「データ作成+ダウンロード」が8時間で「データ作成+全行画面表示+ダウンロード」が86時間というのがあって、これは要するに画面表示が遅いということですか。

○岩尾参考人 これは結論からいいますと、個人ネットワークというネットワークドライブを利用しておりましたので、その遅さが主な原因になっていたようです。画面表示に関しては、それほど関係ないと思っております。

○山本座長 この個人ネットワークというのは何のことですか。

○岩尾参考人 サーバー上で富士通さんが用意してくださっている領域でして、基本的にローカル領域ではなく、ネットワーク上の領域であります。

○山本座長 サーバー上の領域。

○岩尾参考人 はい。

○山本座長 なるほど。わかりました。

 あと、もう一つ技術的な話ですが、Rでメモリがなくなるのは非常によくある話で、多分、中身を小分けにするなどで対応することが多いと思うのですが、もう一つは、ページングで対応すると、今のRは8TBまで使えると思います。そうすると、このRはページングメモリに対応しておらず、物理メモリだけで動いているということですか。もちろん分かればで結構です。

○大寺参考人 済みません。詳しいところまではわかりません。

○山本座長 ページングモードにするのは簡単ですが、ページングモードにすると、メモリではなくてディスクとの間にスワップが起こるのでスピードが落ちるのですね。どれぐらいスピードが落ちるのかは、こういう大規模データを使うときには非常に興味のある部分で、もしわかれば、後で一度確認をしていただければと思います。

 それから、今度は技術的な話ではなくて、東京大学のオンサイトセンターでは、あの部屋で、例えば8時間作業して待つというのは非常に辛いという感想があったのですが、それは京都大学のオンサイトセンターでも同じですか。時計も窓もない部屋でずっと作業をする苦しさというのは、やはり感じられましたか。

○岩尾参考人 そうですね。現実的に8時間待っているかどうかは別としても、やはり作業環境的には密室のような環境ですので、知らず知らずのうちに精神的に参っていくようなことはあるかもわからないです。

○山本座長 なるほど。よくわかりました。

 あと、BIツールはプルダウンで選んでいくのですけれども、東大での御意見として、結局条件がand なのか or なのかわからないといった要するにマニュアルの説明不足のような指摘がありましたが、同様にお感じになりましたか。それとも、この程度は割と簡単にできるのか。ただ、今回はほとんどBIツールを使われていないのですね。

○加藤参考人 ありがとうございます。

 研究者の目線で言うと、BIツールでの集計の次には、例えば回帰分析など、複雑な作業を考えるだろうということ、更にそうした作業のほうがはるかに時間を要するおそれがあるだろうということからので、BIツールはその後それほど検証しておりません。件数につきましても、高血圧や前立腺肥大での検証作業で、データセンターの負荷がかかっていないときにはそれなりの時間で集計できたことと、あと、御指摘ありました性別ですとかその他の個々の患者の属性条件を加えたとしても、余り時間は変わらないだろうという手応えを得ましたので、それ以上余りBIツールはさわっていないということでございます。

○山本座長 わかりました。どうもありがとうございました。

 ほかに何か御質問、御意見ございますでしょうか。

 どうぞ。

○加藤参考人 今回、このパフォーマンステストの機会をいただきまして、私どもも研究費の目途がつきましたので、今日ご発表させていただいた、各種医療データを取る扱ってきた研究者に加わってもらい、一緒にチームを組んでやらせていただきました。その過程で感じましたことは、医療情報の専門家だからNDBも分析できるだろうとか、あるいはレセプトをよく知っているからNDBを自在に解析できるだろうとか、そういうレベルではもうなくなっているな、ということです。多くの人は、たとえばDPCデータの解析ができたらレセプトの解析もできるのではないか、情報のことに詳しければNDBの操作もすぐできるのではないかと思われるでしょうが、今回発表した各者とも、知らないことがとても多くてびっくりした、というようなことを当初申しておりました。私はすごく印象深く思いました。

 これは逆に言いますと、多くの方にこのデータを頻繁に扱ってもらわないと、なかなかNDBの解析スキルのある人材の養成にはつながらない、ということを意味するのではないでしょうか。今回発表の機会をいただいたこの3名も、このところ毎日データの操作や、その検証に携わってもらっております。そうすることで、もともと素地がありますので、NDBに関する様々な知識やスキルを短期間で身に付けてもらっています。また、実際の研究にも携わってもらっていますので、医療そのものに関するディスカッションにも深く踏み込んでいくこととなり、先ほど石川先生から御指摘あったような、医学・医療へのリテラシーも身についてくるようになります。

NDBについてはデータ利用にあたって様々な案件や審査の手続きがあり、誰もが扱えるデータという位置付けではないと思います。しかしそれでも、利用する人、適切に利用できる人が増えることが、このデータの有用性を高めるための非常に重要なポイントになるのではないかと感じました。ですので、NDBを扱える研究者が増えるような仕組みですとか、それを維持できるような体制があると、いろいろな形でNDBを使った研究、NDBを使った政策というのが発展していくなと感じた次第です。

 ありがとうございます。

○山本座長 ありがとうございます。

 ほかに何か構成員のほうから御意見ございませんでしょうか。よろしゅうございますか。

 一応、ほぼ予定どおりのパフォーマンステストをやっていただいたとので、本来の、模擬申し出で研究テーマが出ているので、そちらに進んでいただいてよろしいかと思いますが、よろしゅうございますか。

 それでは、本来の研究テーマもある意味、オンサイトリサーチセンターのテストですので、引き続きよろしくお願いいたします。

 それから、前回の東大でもお話した通り、やはりあの中に長い間いるとかなりストレスフルで、これは誰がやっても同じだと思うのです。したがって、あそこからどうやってデータを出すかも一つの大きなテーマだと思うのです。つまり、出すためには再申請は必要ですが、我々がNDBでやる単純集計情報ではなくて、研究者がつくった集計情報として安全性を説明していただいた上で、研究室に持ち帰ってそれで十分研究していただくという流れを確立することが大事だと思うのです。そういう点を含めて、ぜひお願いをしたいと思います。

 これでよろしいですか。

 それでは、どうもありがとうございました。

 それでは、議題の2つ目「レセプト情報等の民間提供について」、事務局から説明をお願いいたします。

○赤羽根室長 そうしましたら、事務局から御説明をさせていただきます。資料2「レセプト情報等の民間提供について」をごらんいただければと思います。

 資料2、1ページ目、以前の有識者会議に出た資料ですけれども、民間提供の議論のまとめを載せさせていただいております。民間提供については、25年の日本再興戦略や社会保障制度改革国民会議の報告書なども踏まえまして、ワーキンググループで模擬申し出の議論等々をしておりました。それを踏まえて、模擬申し出いただいた6件の申し出については、2件について個別の集計を行うということで進めさせていただいております。

 そのうち1件について、日本医療機器テクノロジー協会の申し出については、既に平成28年5月に抽出結果を公表しております。一方で、日本製薬工業協会からの申し出については、今準備を進めているという状況になっています。

 また、今後について、民間提供の対応については、個別申し出にかわりましてNDBオープンデータの作成過程で、民間企業等からの提案も受け付けていくということで考えております。

 2ページ目、先ほど申し上げました模擬申し出の検討結果を改めて載せさせていただいております。医療機器テクノロジー協会の申し出については、公表を行っております。製薬工業協会からの申し出については、現在準備を進めているところで、現在のステータスとしましては、集計を行う集計対象の薬剤について、製薬工業協会のほうで選んでいただいたという状況になっております。

 3ページ目、これも何度かお出ししている資料でありますけれども、製薬工業協会の申し出の概要を載せさせていただいております。基本的には、市販後の安全性評価並びに臨床開発におけるニーズ調査の情報源としてのNDB定型・半定型表の仕様の検討並びにその利活用の普及啓発ということを書いていただいております。

 4ページ目から、具体的に抽出対象ということで選定いただいた薬剤をリストとして出させていただいております。基本的にはこの4ページ目と、次の5ページ目にまたがっておりますが、24の薬剤を選んでいただいております。薬効に関することとしましては、生活習慣病に対するお薬とか抗がん剤のようなもの、それから抗ウイルス剤とか抗菌薬といったようなものが含まれております。

 医薬品医療機器安全性情報を参考にして、処方推定患者数とか、PMDAの報告件数等々を横に入れさせていただいております。

 6ページ目に集計表のイメージを載せさせていただいております。基本的には各年齢区分の患者数ですとか使用量といったデータで、右のほうに行きますと、例えば肝疾患が入っているかどうかとか、肝不全・肝硬変あり、そういった方に使われているかどうかみたいなことも入ってまいります。イメージとしましては、この集計表を24の薬剤について作成するということでございます。

 7ページ目から、参考資料として少しつけさせていただいております。

 8ページ目は、合併症有無のところで具体的に、例えば肝疾患ありとするとき、どういう定義で肝疾患ありとするのかとか、そこら辺のロジックの出典を少し入れさせていただいております。

 9ページ、10ページ目は、これまでの経緯等々に関するものを入れさせていただいております。今回は、この24の薬剤について集計作業に入ってもよいかということで御確認をいただければということで、お願いをさせていただきたいと思っております。

 事務局からは以上でございます。

○山本座長 ありがとうございました。

 ただいまの事務局からの説明に関しまして、御意見、御質問がありましたら、どうぞよろしくお願いいたします。

 テストを繰り返してようやくできるとわかったところで、対象薬剤を24薬剤に絞った上で、6ページの集計表はあくまでもイメージですが、この24の薬剤について作って公表したいということです。

 6ページの「…」のいわゆる合併症有無のところは8ページに、8ページの合併症有無のところはこれで全てですか。

○赤羽根室長 おっしゃるとおり、これで全てでございます。

○山本座長 ということでございます。いかがでしょうか。

 どうぞ。

○頭金構成員 現在、集計中で公表の準備を進めているということですけれども、今後のスケジュール等がわかりましたら、教えていただきたいと思います。

○吉村室長補佐 事務局でございます。

NDBは一つのサーバーでデータ処理しておりますので、お答えとしましては、他の抽出ないしは作業等の進捗の兼ね合い次第ということになります。ただし、できれば早期に抽出を終了して公表したいと考えておりますので、今年度内に一定のめどをつけたいと思っております。

 以上です。

○山本座長 ほかにいかがでしょうか。

 どうぞ。

○大久保構成員 細かいところですが、8ページに合併症の有無を判断すると書いてありますが、この分析ですと、糖尿病薬を飲んでいる人は糖尿病という病名が入るわけですね。それとも、この糖尿病ありというのは、ICDの番号がありますけれども、これは合併症的な糖尿病ということになるのか、ちょっと確認です。

○吉村室長補佐  糖尿病の薬剤の集計については、糖尿病そのものは合併症には該当しないという事になりますので、他の薬剤の使用時に、こちらのICD-10コードに該当する傷病名が入っているか否かという事で合併症の有無を暫定的に判断していくという事でございます。

○山本座長 ありがとうございます。

 ほかはいかがでしょうか。よろしゅうございますでしょうか。

 それでは、これはこのように進めていただくということで、よろしゅうございますか。

 ありがとうございます。

 次に、本日の議題の3つ目「その他」について、事務局から説明をお願いいたします。

○赤羽根室長 事務局でございます。

 その他ということで、今回、議事には明確にお出ししておりませんが、御報告ということで、事務局から少しだけ御説明をさせていただければと思っています。

 参考資料として入れさせていただいております「データヘルス時代の質の高い医療の実現に向けた有識者検討会の開催について」という紙をごらんいただければと思います。

 基本的にこの有識者会議とは別の動きではございますが、ことしの春から、支払基金の改革に関しまして、データヘルス時代の質の高い医療の実現に向けた有識者検討会というものが開催されております。その中で、ごらんいただければわかるかと思うのですけれども、ICTとかビッグデータという言葉が出てきておりまして、この有識者検討会の中でも、こうしたデータの活用という話が一つ重要な話題として入ってきておりますので、この有識者会議でも御報告させていただくという次第でございます。

 めくっていただきまして、2ページ目に有識者検討会の構成員のリストがございまして、西村周三先生が座長をされておりまして、本検討会座長の山本先生も構成員としてお入りいただいております。

 さらにめくっていただきまして、3ページ目でございます。これは平成28年7月8日付ということで整理案を出されているものなのですけれども、この有識者検討会の現在の流れとしては、とりあえず(1)として書いてある審査に関する話と、(2)に書いてあるデータ活用の話ということで、それぞれワーキンググループに分けて検討を進めていこうという話になっております。恐らくそのワーキングの検討を受けて、秋以降、この検討会の本体が動くという状況ではないかと思っております。恐らくデータ活用のところで何らか、例えばNDBに関することが話題になる可能性もあるかと思っておりますので、今回、御報告をさせていただいた次第でございます。

 事務局からは以上でございます。

○山本座長 ありがとうございました。

 当有識者会議とは一応別の会議ですけれども、御説明をいただきました。

 何かとりたてて御質問とかはございますでしょうか。よろしゅうございますかね。NDBに関係する話題が出たときには、また御報告いただくということで進めていただければと思います。

 全体を通して何か御意見、御発言がございましたらお受けしたいと思いますけれども、いかがでしょうか。よろしいですか。

 それでは、本日用意した議事は以上であります。

 事務局から何かお知らせはございますでしょうか。

○赤羽根室長 事務局でございます。

 次回の本会議の日程でございますが、次回は9月下旬を予定しておりますので、詳細はまた追って御連絡をさせていただきます。

 本日はありがとうございました。

 事務局からは以上でございます。

○山本座長 それでは、これで閉会とさせていただきます。

 本日は、お忙しい中御参集いただき、ありがとうございました。


(了)

ホーム> 政策について> 審議会・研究会等> 保険局が実施する検討会等> レセプト情報等の提供に関する有識者会議> 第32回レセプト情報等の提供に関する有識者会議 議事録(2016年7月27日)

ページの先頭へ戻る