ホーム >
政策について >
審議会・研究会等 >
医政局が実施する検討会等 >
医療等情報の二次利用に関する技術作業班 >
2024年３月６日　第２回医療等情報の二次利用に関する技術作業班議事録

2024年３月６日　第２回医療等情報の二次利用に関する技術作業班議事録

日時

令和６年３月６日（水）１５：３０～１７：３０

場所

オンライン開催

出席者

構成員（五十音順、敬称略）

足立昌聰
小笠原克彦（座長）
岡田美保子
岡村浩史
清水央子
田辺里美
山口光峰

議題

（１）前回の技術作業班で頂いた主なご意見について
（２）医療等情報のデータ標準化、信頼性確保及び情報連携基盤の構築に係る課題等について

議事

議事内容: ○室長補佐（岡）　事務局でございます。
　定刻になりましたので、ただいまより第２回「医療等情報の二次利用に関する技術作業班」を開催いたします。
　皆様におかれましては、御多用のところ本作業班に御出席いただきまして、大変ありがとうございます。
　本日の会議はオンラインによる開催としまして、会議の公開につきましては傍聴用Zoomウェビナーで行うこととしております。
　構成員の皆様は、会議中御発言の際は「手を挙げる」ボタンをクリックしていただき、カメラをオンにしていただきますようお願いいたします。指名を受けましてからマイクのミュートを解除して御発言をお願いいたします。御発言終了後は再度マイクをミュートにしてくださいますようお願いいたします。
　次に、本日の構成員の出席状況について申し上げます。今、山口先生が御参加中というところですけれども、本日は全ての構成員の皆様に御出席をいただく予定としております。
　次に、資料の確認をさせていただきます。議事次第、資料１、資料２－１から２－４、参考資料１及び参考資料２でございます。
　不備等ございましたら、事務局までお申しつけいただければと思います。
　今、山口先生がお入りになりました。全ての構成員の皆様に御出席をいただいております。
　事務局からは以上となります。
　それでは、小笠原主査、議事進行につきましてよろしくお願いいたします。
○小笠原主査　小笠原でございます。どうぞよろしくお願いいたします。
　本日の議題は既に議事次第にございますように、２つでございます。１つは、前回の技術作業班でいただいた主な御意見について議論したいと思います。２つ目は医療等情報のデータ標準化、信頼性確保及び情報連携基盤の構築に関する課題についてでございます。議題１、２が審議事項となっております。
　まず、議題１ですが、資料１につきまして事務局から御説明をお願いいたします。
○室長補佐（山崎）　事務局です。
　資料１を御覧ください。第１回技術作業班でいただきました主な御意見を御紹介します。
　まず、検討項目（１）医療等情報の二次利用におけるデータ標準化、信頼性確保についてです。各医療機関に対しマスタを適用していく手順を示すことが信頼性確保に有用ではないか。必ずしも知見がある担当者がデータを管理していない状況があるので、ガイドのようなものがあると参考になる。
　６情報は、国際的なコモンデータモデルであるOMOPとも相性がよく、二次利用を進めていく上で国際的な共同研究の視点も重要である。二次利用を促進するために標準化が非常に重要ということはこれまでもずっと指摘されてきたが、なかなか進んでこなかった。イニシアチブを取って要となる組織が必要なのではないか。また、そのような組織では医療等情報の取扱いに関するルールの発信なども担っていくことが考えられるのではないか。
　データの欠損などは情報連携基盤上では補えないので、入力時点で医療機関において標準化されたものがきちんと入力されていることが重要である。
　データの品質に関して、例えばレギュラトリーの目的に耐え得る品質を担保していくためには、MID-NETの取組が参考になる。
　標準コードとしてICDやJLACの話がありましたが、何を使うか、運用面も考えつつ、関係者と連携していくことが重要。
　医療機関のデータ入力についてある程度ルールを決めて、入力側が強制力やメリットを感じるような形でグリップしていくことが必要ではないかといった御意見をいただきました。
　続きまして、検討項目（２）情報連携基盤に関する検討事項についてです。安全管理措置の部分はHICを参考にするのがよいのではないか。一方で、利用者側に求める要件としては、利便性を考慮して、HICを参考にしながら簡略化していくことがいいのではないか。
　また、ガバナンスを標準化する観点だと、HICのセキュリティ監視の部分は踏襲して共通で使っていくのがあり得るのではないか。Visiting環境については、許されたユーザーだけアクセスできるということであれば、ガバナンスも担保できるし、利便性も上がるだろう。
　セキュリティの要件を考えるに当たっては、どのような情報が扱われるかということとセットで、リスクベースで議論することが必要。
　セキュリティを考える上でコストや利便性も考慮する必要がある。守るものに格付をつけてセキュリティ対策を行う方向性もある。また、ネットワーク上はゼロトラストと捉えて、利活用者が身分を証明してもらうことによるセキュリティ対策を講じていくべきではないか。
　技術的なセキュリティだけでは難しい部分があり、利活用者の倫理観を醸成するため講習を受けていただくような対策も重要ではないかといった御意見をいただきました。
　以上でございます。
○小笠原主査　ありがとうございます。
　それでは、今の御説明につきまして御質問、コメント等ございませんでしょうか。構成員の皆様方、いかがでしょうか。山口構成員、お願いいたします。
○山口構成員　御説明いただきありがとうございます。私のコメントはわかりやすくまとまっていると思います。ありがとうございます。
　２つ意見があります。１つ目の意見です。標準化と信頼性確保については、資料に記載されていることに間違えないと思います。一方で、今回の検討会では対象とするデータベースとしていろんなあがっておりますので、データベースにあわせた議論が必要になると思います。厚生労働省の管轄する公的DB、電子カルテ共有サービス、標準電子カルテのデータベース、次世代医療基盤法の事業者が保有するデータベースがあがっておりますが、全て同じ基準で考えることは難しく、目的に応じて検討する必要があると思います。また、どのデータベースをターゲットにするのか、法改正等を行い強く権限を持って見直すのか等を明らかにしたほうがいいと思います。おそらくですが、本検討会で決まった内容を民間のDBに適用してくださいと言ったところで、開発資金の負担をどうするか等厳しい問題があるため、実現しないと思います。そのため、検討する範囲については実現性を考え整理したほうがいいのではないかと思いました。
　２つ目が、MID-NETを参考にということは非常にありがたいと思います。MID-NETの運営管理の知識・経験はなるべく提供させていただきますが、一方で、データベース毎にどこの部分を参考にするのかというのをよく考えていただければと思います。例えば電子カルテ共有サービスや標準電子カルテにおける情報収集や解析する仕組みにおいては、MID-NETの知見が非常に参考になると思いますが、民間DBについては、営利目的でやっており、既に知識があると思いますので、MID-NETを参考にしてくださいというのは変なのかなと思いました。
　以上です。
○小笠原主査　ありがとうございます。
　今の点につきまして厚生労働省から何かございますか。
○企画官　厚生労働省事務局でございます。
　山口構成員の御意見、ありがとうございました。
　ターゲットを明確にすべしといったことは、まさに御指摘のとおりかと思っております。今回の技術作業班の中でも論点の一つにはなっておりますが、最低限は厚生労働大臣が保有している医療・介護の公的なデータベースを対象にこの情報連携基盤は構築していきたいと考えております。その上で、厚生労働大臣以外の保有主体の様々なデータベースがありますので、そういったものをどこまでこの情報連携基盤の上で取り扱うことにしていくか、その際のいろんな要件としてどういったものがあるかについても、ここで御意見をいただきたい論点の一つかなと思っているところでございます。
　また、MID-NETのどの部分を参考にという御指摘、ごもっともかと思っておりますので、前回山口先生からいただいた御提案を踏まえて、どういったところを取り入れていけそうかというのをぜひ検討させていただきたいと思っております。
　以上です。
○山口構成員　私のコメントに丁寧に御説明いただきありがとうございました。
　以上でございます。
○小笠原主査　それでは、岡田構成員、よろしくお願いします。
○岡田構成員　岡田でございます。
　前回の取りまとめ、ありがとうございます。
　私のほうは、本日のアジェンダを拝見していて、今後の議論をどのようにお進めになられるかが把握できなかったので、ちょっとお伺いしたいと思ったのですが、今ほどの山口構成員の御意見とも若干重なるのですけれども、多くの課題、特に標準化については、様々な御意見の中で割と集約していくべきところも多々あるかと思うのです。それで、今後の進め方、あるいはタイムライン的に本作業班としていつ頃までにどういうことを決めていくのでしょうか。
　例えば本日思いましたのは、課題を抽出して、それを整理して、意見を集約して方向性を見出していくような流れになっていくのかなとも思ったのですが、その辺を教えていただければと思いました。
○小笠原主査　厚生労働省、いかがでしょうか。
○企画官　事務局でございます。
　岡田構成員、御質問、御意見ありがとうございました。
　今後の進め方についてはまた整理をしてお示しをさせていただきたいと思います。今回の技術作業班で岡村先生、田辺先生、足立先生から御提案をいただきますので、これで構成員６名の方から御提案をいただいた形になりますので、それも踏まえて、この中からどういった点を今後検討していくべきかをある程度整理をさせていただきたいと思います。
　また、後ほど御説明をさせていただこうと思っていましたが、前回と今回で御説明いただいた内容については、親会であります二次利用ワーキングのほうに次回御報告をさせていただきたいと思っております。そちらのほうは春頃には一定の議論の整理をしたいと思っておりますけれども、今回の技術作業班で扱っていただいている内容につきましては、もう少し継続的な議論が必要だと思っております。標準化とか信頼性確保、情報連携基盤のセキュリティなどについては、ある程度継続的な議論が必要だと思っておりますので、春以降もしっかりと課題などを整理した上で、ある程度継続的な御議論をお願いしていきたいと今、考えているところでございます。
　以上です。
○岡田構成員　ありがとうございました。
　お聞きした理由は、急ぐべきところが非常にあるという印象も持っておりまして、論点整理、課題整理、意見集約、それからこの作業班としての提案ということをまとめていっていただけると認識しておりますが、それをどんなタイムラインでお考えでおられるのかというのをお聞きした次第でした。
　本日、また構成員の御意見、資料提供を承って、そしてまた意見を伺って、それからになると。少し継続的に意見交換をしていくということになるということで理解しました。それでよろしいでしょうか。
○企画官　はい。
○岡田構成員　ありがとうございます。
○小笠原主査　それでは、田辺構成員、よろしくお願いします。
○田辺構成員　田辺です。
　取りまとめ、どうもありがとうございました。私のほうから挙げたコメントなども丁寧に、また簡潔におまとめいただいて、どうもありがとうございます。
　主にセキュリティに関してお話を差し上げたところでございますが、今、セキュリティ対策に関して、どうしてもこれだけいろいろなインシデントが起きますと、どこまでも対策を打ちたくなってしまって、なかなかコストとのバランスが難しいということで、ほかの先生からも御意見としてリスクベースで議論しましょう、という御意見もございましたが、関与している方々の視点に偏ってしまうようなところがあって、アセスメントをするときも業者さんによってお得意な分野に注力されてしまったりということもございますので、網羅的にアセスメントをしていく必要があるというところには留意が必要かと思います。
　最初のところで少し丁寧に調査をした上で、打つべきところに対策を打っていくという流れで無駄のない、無理のないセキュリティ対策が打てるかなと思いますので、少し丁寧に網羅的にアセスメントをしていくということもアプローチとしてあるのではないかなと思っております。
　それから、ほかの先生からも御指摘がありましたとおり、今後さらに具体的なセキュリティ対策をどのように施していくかという実装レベルのところのお話に入ってまいりますと、セキュリティですので、オープンにしていける情報と少しクローズなところで検討していくべきところがあります。どういうセキュリティ対策が打たれた基盤なのかというところがあまりにも赤裸々に表に出ていくのも、そこがセキュリティホールになりかねませんので、慎重に議論して進めていく必要があるかなと感じている次第でございます。よろしくお願いいたします。
○小笠原主査　事務局、何かございますか。
○企画官　ありがとうございます。事務局でございます。
　今の田辺先生の御指摘も踏まえまして、今後の特にセキュリティ要件の議論の仕方については、また小笠原主査、構成員の皆様とも御相談をさせていただきながら、そのやり方も検討させていただきたいと思います。
○小笠原主査　ありがとうございました。
　他はよろしいでしょうか。
　それでは、議題２に入りたいと思います。議題２は「医療等情報のデータ標準化、信頼性確保及び情報連携基盤の構築に係る課題等について」でございます。
　今回の技術作業班におきまして、情報連携基盤において設けるVisiting解析環境やセキュリティ要件が検討項目となっておりますが、改正次世代医療基盤法においても、認定事業者がVisiting環境を整備することも可能とされているところです。本作業班におきましても参考となる取組と考えられることから、内閣府健康・医療戦略推進事務局から次世代医療基盤法におけるVisiting環境の考え方について御説明いただき、質疑応答等の時間を取りたいと思っております。その後に３名の構成員の先生から御発表いただきたいと思います。
　それでは、内閣府から資料２－１の御説明をお願いいたします。
○内閣府（健康・医療戦略推進事務局）　内閣府の阿南でございます。
　ただいま御紹介がありましたとおり、改正次世代医療基盤法のVisiting環境に関する考え方ということで、御説明させていただきたいと思います。
　改正次世代医療基盤法においては、新たに仮名加工医療情報という仕組みを創出されましたが、これはセキュリティの観点から、仮名加工医療情報の提供は国が認定した利活用者に限定するとさせていただいているところです。これまでの匿名加工医療情報の利活用者に認定は必要がなかったのですが、今後は、仮名加工医療情報の利活用者に認定が必要になり、利活用者の利用する環境についても私どもで認定するということになっております。
　なお、現在この改正法というのは施行されておりませんで、今年の５月まで改正法を施行しなければいけないということで、案は対外的に説明させていただいているところですが、現在調整中のところでもありますので、今後変更があり得るという点を御承知おきいただけたらと思います。
　まず、認定作成事業者の安全管理措置に関する考え方ということで、認定利用事業者の認定の類型として２類型設けることとしています。それは確実な安全管理措置の確保と、仮名加工医療情報の利活用の促進の両立の観点からこうした２類型を設けたところでございます。
　その２類型の内容を申し上げますと、利用事業者が自ら整備した環境の下で仮名加工医療情報を保存することが可能なＩ型類型と、データベースをつくった作成事業者が整備したVisiting環境での利用に限定して、その環境の中で利用していくというⅡ型認定の２類型を設けることとしています。
　模式図が下にありますけれども、Ｉ型は、作成事業者が仮名加工医療情報を作成して、利用事業者のほうに提供します。Ｉ型認定のほうはそれを受け取って、利用事業者で保存します。Ⅱ型認定につきましては、作成しました仮名加工医療情報を提供はするのですけれども、こちらのほうで受領・保存しない。利用事業者のほうでは保存しないという形を取るということです。
　そのとき、Ｉ型認定では、当然利用事業者でデータを持っておりますので、その環境の中で管理区域と取扱区域というものをつくってもらって、仮名加工医療情報が保存されている機器等がある区域を管理区域としていただき、別途区域を設けていただいて、こちらの取扱区域のほうで解析等々の作業をしていただくということを想定しています。
　一方、Ⅱ型類型のほうではデータの保存がありませんので、管理区域というものはない。取扱区域のみがあるわけですが、このときVisiting環境で利用するということになりますが、２つ考えておりまして、１つは、利用事業者が利用事業者の何らか施設等でリモートアクセスを通じて作成事業者のほうにアクセスしてデータを扱います。それから、オンサイトリサーチセンターというのは、MID-NETとかでもやっていらっしゃると思いますけれども、そうした作成事業者のほうでつくった環境、施設設備等々の中で取り扱う。この２つの類型を考えているというところでございます。
　特に安全管理措置に関する基本的な考え方については、これはVisiting環境に限らず、Ｉ型、Ⅱ型等も含めてなのですけれども、利用事業者というのは利用の仕方がそれぞれあって、利用環境もいろいろあるでしょうから、どういう管理区域、取扱区域を設けて取り扱うのかというのをリスク分析していただいて、それに基づいてしかるべき具体的な措置を取っていただくということを考えております。
　下のほうにこちらは管理区域、取扱区域で、それぞれの脅威の考え方とか取るべき措置を示しているところですけれども、ここは例として出しているものであり、全部取ったからよいということでもないし、全部取ってくださいということでもないと。それぞれリスクをベースにして考えて、それぞれ取るべき措置を考えていただきたいということでございます。
　附属して申し上げますと、先ほどのⅡ型類型、Visiting環境でのみ仮名加工医療情報を取り扱うというところですが、作成事業者のほうの環境やシステムに応じて使うことになりますので、その辺は全て利用事業者でこういう安全管理措置を取るというわけではなくて、作成事業者の講じたVisiting環境の措置との組合せによって必要十分な安全管理措置を総合的に整備することが必要だと考えております。
　こうした安全管理措置の例は、参考資料のほうにつけております。
　以上が利用事業者側のほうの話でございますが、データベースをつくるほうの認定作成事業者のほうでやるべきことも、ガイドライン等で示していくことにしています。
Visiting環境だけに限った話ではないのですけれども、認定作成事業者が認定利用事業者に対して審査したり、提供の在り方を決めたり、監督をするということにしておりまして、ちなみに申し上げますと、審査というのは、作成事業者側で審査委員会を設けて、倫理なり科学的な観点から審査するということでございます。
　今回安全管理措置に特に関係するというのは、資料の②（２）だと思いますが、作成事業者が利用事業者に対して仮名加工医療情報を提供する方法や、提供後の監督の在り方も今回ガイドラインで示す予定にしておりまして、そういったことで、作成事業者としても利用事業者に対する提供、利用の際に適切な取扱いが確保されるように求めることとしています。
　詳しく申し上げますと、こういったことを作成事業者と利用事業者の間で取り決めていただく必要があるとしておりまして、取り決める内容として例示で書かせていただいておるとおり、安全管理措置についてはこうした利用目的とか、利用の範囲、提供の方法、提供の方法を含める必要があり、今回次世代医療基盤法ではVisiting環境以外でも提供方法がありますので、従来の通信で提供する方法ということも書きつつ、Visiting環境についても取り決めをしていただきたいというふうにしております。
　Visiting環境について、提供の在り方を詳しく書かせていただいているのが次のページです。通信で送るということもありますけれども、Visiting環境を構築して、Visiting環境で提供するのであれば、利用事業者の認証方法について要件を設けてくださいとか、ログの保存方法をこうした形で措置してくださいとか、暗号化してください、設定もこうした形でしてくださいということをお示ししているところです。
　作成事業者により利用事業者を監督するとさせていただいていますが、Visiting環境でデータを使わせる際にも監督していただく必要もあると考えておりまして、その方法はこれに書かせていただいているところですが、特に関係してくるものとしては、これも取決めでしていくことが必要なのですが、仮名加工医療情報利用終了時にはこういった形で取決めをしてくださいとか、特にⅡ型のときはVisiting環境で利用する際にはアクセスログ等々で監視するとか、異常が発生したことが分かるようにして、それで制御するような体制で運用してくださいということも例示として出させていただいております。
　さらには、安全管理措置に関わってくると思いますけれども、よりよい利用環境が利用事業者から要望があると思いますが、例えば作成事業者側から提供されるデータ以外にも独自データと突き合わせて解析したり、独自の解析ツールを使いたいとか、持ち出しも仮名加工医療情報ではないと言い切れない状態で持ち出してもらっては安全管理上問題があると思いますので、そういったことについても取決めをしていただくということをこのガイドラインでは示しているところでございます。
　最後に５ページ目に戻っていただきまして、本会合において、クラウドについても考え方を示してくださいの依頼もあったので説明しますと、事務局内のほうで考え方を今、整理しているところですので、申し上げられることはこれくらいですが、クラウドにつきましては、これまで次世代医療基盤法の中では、いわゆる生データである医療情報をクラウド環境で取り扱うのが難しいような状況でありました。特に次世代医療基盤法のほうで現地確認を求めているところですけれども、クラウドの考え方とうまく合わないところがありましたので整理して、クラウドサービスを使っていきたいという要望も強く、しかるべき安全管理措置ができた上であれば利用可能だということを示していこうとしております。これについては、今回は示すことができないところですが、しかるべき考え方を明確化して、クラウドサービスが利用できるようにしていきたいと思っているところです。
　ここは作成事業者の欄に書かせていただきましたけれども、利用事業者、特に、Ｉ型の認定でデータを受け取って解析するときにクラウド環境を使いたいという場合もあることから、これについてもクラウド利用の考え方というのを今後示していきたいと思っているところでございます。
　内閣府からの説明は以上でございます。
○小笠原主査　ありがとうございます。
　とても重要で、今後の参考になる既に進んでいるお話かと思います。省庁間をまたいだ複数のシステムがあるというのはあまりよくないなと思っていますので、ここは統一しながら進めていく必要性を感じている次第です。
　それでは、構成員の皆様方から御質問等、コメントございますでしょうか。
　後で最後のほうに総合討論の時間を設ける予定でございますので、もし何かあればそのときにでも御質問いただければと思いますので、よろしくお願いいたします。
　では、これから構成員の先生方の御発表に移りたいと思います。資料２－２から２－４につきまして、それぞれ岡村構成員、田辺構成員、足立構成員から順番に10分程度で御説明いただきたいと思います。その後にまとめて質疑応答の時間を取りたいので、よろしくお願いいたします。
　それでは、まず岡村構成員から資料２－２の御説明をお願いいたします。
○岡村構成員　大阪公立大学の岡村です。よろしくお願いします。
　私のほうからは「多施設の電子カルテデータの二次利用の取組から」ということで、この作業班に情報提供させていただくのがいいかなという内容について御提示させていただきます。
　簡単に自己紹介をさせてください。私は工学部を出ておりまして、民間企業でシステムエンジニアとなり、その後医学部に編入して、大阪市立大学で血液内科医として臨床医になりました。その後、臨床研究などに携わった後に、今は血液内科の診療をしながら医療情報の仕事に携わらせていただいているというところになります。
　今日御提示させていただく内容としましては、私が現在関わっております多施設の電子カルテデータの二次利用として、１つ目は全ゲノム解析等実行計画において、AMED事業と事業実施していくための事業実施組織の準備室に参画させていただいておりますので、その内容からGenomics Englandの話とJASPEHRプロジェクトの御紹介。２つ目は、これは私が代表しておりますAMED研究で、造血幹細胞移植患者さんの臨床判断支援システムの開発を行っておりまして、ここで多施設の電子カルテデータを統合しておりますので、そこから気づいたことを御提示させていただきたいと思います。
　まず１つ目、全ゲノム解析等実行計画につきまして。全ゲノム解析等実行計画では、がん患者と難病患者さんの全ゲノムデータと診療情報を統合した情報活用基盤を構築するというところが目標になっております。この図に示しておりますように、左上に患者さんがおりますけれども、患者さんはその病変の検体を提供し、検査会社において全ゲノム解析が行われ、データベースに入っていく。同時に、その患者さんがかかっている医療機関から電子カルテを通じて臨床情報がデータベースに入っていく。これらのデータをひもづけることによって全ゲノムデータと臨床情報が統合されるというものになります。さらに、これらのデータを臨床に還元したり、あるいは製薬企業やアカデミックな研究者を含めた研究に活用していくというところがこの事業の目的になります。
　このような取組は世界で先行事例がありまして、特に英国のGenomics Englandが非常に近い取組をされておりますので、こちらの仕組みを参考にしながら進めているというところになります。
　これがGenomics Englandの全体図になります。まず左側にゲノム医療センター、すなわち13か所の病院があります。13か所の病院から検体と臨床情報が提供されます。検体のほうはシークエンスがかけられ、臨床情報と共に４番のデータセンターに統合されます。通常患者レジストリはこういうものですけれども、Genomics Englandの面白いところは、さらに左上の紫で囲っている部分、いわゆる複数の公的データベースを統合し、その公的データベースの情報もこのデータセンターに集めています。つまり、４番のところに集まるデータの付加価値を上げ、それを産業界やアカデミアに研究活用してもらうという仕組みになっております。
　これは少し見方を変えているだけですけれども、右上のほうにPrimary clinical dataと書いています。これが各病院施設からGenomics Englandに集める情報になります。Secondary dataというのが次にあるのですが、こちらがいわゆる公的データベースで、Hospital Episode Statisticsというのは、日本で言えばNDBに当たるようなものでレセプトデータになりますし、NCRASというところは、日本で言えばがん登録の情報に近いものになります。すなわち、Primary clinical dataとして、病院のデータ、Secondary dataとして公的データベースのデータというものがひもづいた形でデータベース化されているというものになります。
　少しシステムの構成を整理しますと、右側にPrimary clinical data、Ａ施設、Ｂ施設と書いていますけれども、このように各病院から患者さんの臨床情報が集まってくる。一方で、Secondary clinical dataとして、左側にあるような、まさに今回情報連携基盤として考えられているようなレセプトデータや死亡情報、がん登録の情報がSecondary Uses Serviceにまとめられて、そのデータがGenomics Englandに提供され、ゲノム情報と各病院のPrimary clinical dataとひもづけられて、研究者にVisiting環境で提供されるというシステム構成になっております。
　ということで、本邦においても全ゲノム解析のデータベースをつくる上において、Genomics Englandのシステム構成を日本版として当てはめるとなると、このような形になるのかなと。Primary clinical dataは同じような形で、左側のSecondary clinical dataというところに情報連携基盤のような形で公的データベースをたくさんひもづけ、さらにゲノム情報をひもづけて、研究者に使ってもらうような統合データベースを目指すものと思っております。
　ということで、先ほども少し議論に出ましたが、情報連携基盤に集まったデータをほかのデータベースとどのように連携するのか、あるいはどのような要件を満たしたデータベースなら連携していいのか。また連携するにしても、全ゲノム解析研究に参加する患者さんというのは特定の患者さんであって､一方でSecondary clinical dataの患者さんは全国民を対象にしているデータになりますので、この研究に参加している患者さんに絞るような形でデータ提供しなければいけない。そういう機能的な要件も必要になってくると思いますので、議論していく必要があるのかなと感じています。
　２つ目は、全ゲノム解析計画で取り組まれているJASPEHRプロジェクトというもののご紹介になります。JASPEHRプロジェクトは、国立国際医療研究センターの美代先生が中心に開発研究を進められているプロジェクトです。先ほどPrimary clinical dataとして各医療機関からデータを集めるという話をしましたけれども、標準規格は通常、各病院からデータを集めるときに標準化しましょうというように、収集時に利用するのが普通なのですが、JASPEHRプロジェクトの独創的な点は、収集よりもっと上流であるデータを集める前に標準規格を使いましょうというところにあります。具体的には、収集データ項目の定義として、標準規格であるFHIRを使いましょうというのがJASPEHRプロジェクトのコンセプトになります。
　一体どういうことかといいますと、左側に共通のテンプレート設計図とありますけれども、例えば何とかがんの診断時にこういう問診を取る、あるいはこういう診察をする、あるいはこういう検査をするといったように、最低限必要な標準的な診療というのがあると思うのですが、このような標準診療テンプレートのようなものを各関連学会が定義し、それをFHIRという標準形式で記述します。その記述されたFHIRのJSONのファイルは各施設の電子カルテベンダーに配布されます。配布されたFHIRのファイルは、各電子カルテベンダーにおいて各電子カルテのテンプレートの形式にコンバートされます。要は、FHIR規格で定義された入力項目の様式に基づいて、各社の電子カルテのテンプレート画面が自動的につくられるという仕組みを各社に開発してもらっているというところになります。
　そうすることで、標準規格であるFHIRで定義された何とかがんの診断時に診察を行う項目が電子カルテのテンプレート画面として実装されますので、そこに医療者が診療に使ってデータ入力していくと。診療においてこの仕組みで入力されたデータは、どの病院、どのベンダーであっても同じFHIR規格であり、そのデータ自体も右側にFHIR Questionnaire Responseと書いてありますけれども、このように同じ形式で出力することができますので、データとして同じ形式、標準規格で診療データを集めていけるということになります。
　これが実際の事例になるのですけれども、左側がFHIRのQuestionnaireという規格を使って診療テンプレートの定義をしたもので、各電子カルテベンダーがその定義に従って自動的に電子カルテのテンプレート画面をつくる仕組みが今、開発されております。そうすると、医療者が入力したデータが右側のように同じ形式で一括収集できるものになります。
　こちらも実際に全ゲノムプロジェクトで収集されている項目をJASPEHRテンプレート定義に基づいて電子カルテベンダーが電子カルテのテンプレート画面を実際につくってみましたというものになります。
　JASPEHRプロジェクトは、診療の業務、現場の運用を標準化することができるというところに大きな特徴があると思います。データの標準化には現場の運用の標準化が必要条件となることが多々あることを、皆様感じられているのではないかなと思うのですけれども、このように現場の運用を標準化して、かつデータも標準化することができるというのがJASPEHRプロジェクトの面白いところです。
　そして、現場の運用を標準化したいというニーズは臨床現場に幾つかの場面があります。例えばレジメンです。今、レジメンは各施設ばらばらのレジメン運用になっていますが、どの施設も他施設と運用を統一するメリットがあるはずです。あるいはクリニカルパスなどもまさに運用、診療を標準化するためのものなので非常に相性がいいでしょうし、臨床研究プロトコルなども同様のことが言えます。従って、このような診療業務に応用することによって、臨床業務の運用も標準化し、さらに統一形式でデータ収集ができるというメリットがあります。ですので、こちらに書いてあるように、診療の標準化、データの標準化の一石二鳥が実現し得るため、二次利用に関しても将来的にはレジメンとかクリニカルパスといったデータが標準形式で集まってくる時代が来るのではないかと期待しているところになります。
　次は、もう一つのプロジェクトであります造血幹細胞移植患者さんのデータの統合というところから気づいたところを御提示します。
　現在の取組としては大阪公立大学、和歌山県立医大、愛媛大学の３施設の造血幹細胞移植という手術をされた患者さんに限って、標準規格のFHIRを使って処方、注射、臨床検査結果という情報を、中心にある統合DBのところに統合し、また患者さん用のアプリを開発してePROを入力してもらい、それらのデータも集めていくと。そこにたまったデータを使って、疾患別CDSSと書いていますけれども、臨床判断支援システムをつくり、危険な状態にある患者さんには受診勧奨のアラートをかける。そういうものを目指して今、開発を進めているものです。
　このプロジェクトを進めるに当たって、これまでも議論に出ていることですが、標準コードの付番というところが１つ課題になっております。
　標準コードの付番については、多施設のデータを統合するときには必ず必要になってくるものですので、これまでFHIRに限らず、J-DREAMSやJ-CKD-DBのように多施設のデータを収集してきたプロジェクトがあると思いますし、今後は６情報も同様の話になると思うのですけれども、現状としてはプロジェクト毎に収集項目に標準コード付番を各医療機関にお願いしているというのが実態で、これはプロジェクトごとの部分最適という言い方ができるかなと思います。
　多施設のデータを収集するときは常に、標準コードの付番・採番というのが必須になりますので、であれば、プロジェクトごとに同じ作業、苦労を繰り返すのではなくて、本邦の全体最適として、誰がどのタイミングでどの範囲を付番するのが適切かというところについて、システマティックなワークフローを整理、整備することが必要なのかなと。そのようなところを目指して今、岡田先生などが参加されているJLACセンターがつくられているところだと思っております。
　こちらの図に示しているように、実は令和元年、５年前に既に検査コードについては体外診断薬の薬事承認時にJLACコードの付番を行うべきという提案がされているようです。このように、検査においては承認時にJLACコードが付番されているというのが全体最適としては理想的だと考えております。
　標準コードの付番を考えるときに、同時に将来ビジョンとして見ておかないといけないのは臨床研究の国際化だと思っています。デジタル化によって、情報はネットワークで時間と空間を超えられますので、臨床研究の国際化というのは必ずついてくるもの。逆に言うと、ついていけないと遅れてしまうものだと思います。
　このような中、前回岡田先生から御紹介がありましたけれども、OMOPという共通データモデルの活用が進められています。これは各施設あるいは各国で形式がばらばらの臨床情報を標準化されたデータ構造、すなわちどういうテーブルで、かつ標準コードもこれを使いなさいというのが厳格に定義されているもので、共通データモデルと言いますけれども、そういうOMOP形式に合わせてデータを出してくださいと。そうすることでOMOPの取組に参加できますよというものになりますが、現在8.1億人の患者臨床データをOMOP形式で各所が持っており、世界全人口の約10％超の臨床データがOMOP形式になってそろえられてきていると。レセプト情報をOMOP化して持っているような国もあるということです。
　このように共通データモデルを使うことによって、どの国もどの施設も同じ形式でデータを持つことが実現されますので、複数のデータベースに対して共通の解析プログラムを適用することができます。その結果、そのような解析を支援する多くの分析ツールが開発され、OMOP用に提供されているということがあります。
　また、同一の解析プログラムを各データベースに配布して、各施設内で分析し、その分析結果だけを中央に集めて統合するというNetwork study方式を取ることができるのですけれども、そうすることによって、各施設の個票、個別のレコードデータを外部に出す必要がないということで、個人情報のセキュリティ上も優れた研究ができます。GDPRがある欧州は個票を外部に出すのが難しかったりしますので、相性がよく広がっていっているのだと思います。
　このような仕組みが既にできていますので、実際に大規模データを使った研究が広がっています。2019年のLancetにはOMOPの形式で490万人の高血圧患者さんのデータを使った臨床研究が発表されています。こちらに「日本」と書いていますが、日本のレセプトデータを出しているものの、研究者の中に日本人はおらず、日本はレセプトデータを提供しただけということだと思います。
　下のほうでは、285万人のCOVID-19の患者さんで高血圧と重症化の関連を検討されたということで、これも多施設の国際研究という形で、ビッグデータを使って解析されているというものになります。
　先ほど紹介したGenomics EnglandもこのようにOMOPマッピングを進めておりまして、これは2024年１月に出された記事ですので、今オンゴーイングでGenomics EnglandもOMOP化を進めているというところだと思います。
　ということで、DXによって臨床研究が国際化することは必然ですので、そこを見据えて標準コードというのは、日本独自の標準コードを付番するのも一旦はいいのかもしれないですが、その先に国際標準コードへのマッピングというところがあるのだということを意識して標準コードを考える必要があると思っております。
　これが最後になりますが、他の臨床試験との衝突リスクについてです。造血幹細胞移植の患者さんのデータを統合する際、治験患者さんのデータを集めてしまった場合、それが知らないところで他の研究に使われてしまうリスクがあるのではないかという意見が出て、どう対応したらいいだろうという話になりました。
　例のところに書いていますけれども、例えば疾患Ａに対して適応拡大を目指す薬剤αに関する治験が走っており、それに参加している患者さんの情報が二次利用データに含まれるとします。その結果、別の研究者が同じような研究テーマで、後方視的に二次利用データを使って研究することが可能になってしまう。大規模なデータをリアルタイムに集められることにより、このようなリスクが顕在化してくるということだと思います。これに対応するには各施設がアクティブな臨床試験の被験者かどうかということを判別できる情報を管理して提供する必要がある。あるいは治験依頼者がユニバーサルな被験者キーを管理し、二次利用DBに提供する必要がある。どちらかの対応が必要になると思います。
　まとめですけれども、イギリスではNHSが管理する複数の公的DBを統合し、それをGenomics Englandと共有することでデータの効率的な利活用を行っています。本邦においても、一定の要件を満たすDBと情報連携基盤の公的DBと連携できるような枠組みの検討が必要です。
　JASPEHRプロジェクトは、運用とデータの両方を標準化したい場面で有用で、将来的にはレジメンやクリニカルパスへの応用が期待されます。
　標準コードについては、誰がどの範囲をどのタイミングで付番して、各施設に反映するのが適切なのか、そのワークフローを国として考える必要があると思っております。
　OMOPは、国際共同研究の共通データモデルとして普及が進んでおりますので、本邦の医療情報の二次利用においてもこのような国際化を見据えたコードの付番戦略が求められます。
　最後に、デジタル化で収集患者数や収集項目が増え、さらに情報鮮度が保たれることでデータの利用可能性は広がる一方で、他の臨床試験との衝突に対応する必要があるかと思っております。
　以上になります。
○小笠原主査　岡村先生、臨床面と国際面からプレゼンテーション、ありがとうございました。とても参考になるかと思います。
　後ほど質疑応答しますので、次に移りたいと思います。
　それでは、田辺構成員から資料２－３の御説明をお願いいたします。
○田辺構成員　御紹介にあずかりました構成員の田辺と申します。改めましてよろしくお願いいたします。
　私は医療とは少し違う世界で、独立行政法人の情報処理推進機構、セキュリティと情報化の推進をしております法人にいる関係で、今日は情報セキュリティに関して少しお話をさせていただきたいと思います。
　今回の二次利用の作業班の中で検討の事項として整理をいただいております中に安全管理に関する要件ということで、赤枠で囲った部分のお話について御説明申し上げますので、よろしくお願いいたします。
　この辺りは皆様、もう既にお聞き及びというか、よく聞く話かと思いますが、医療機関の情報システムの利用環境が昨今著しく変化しまして、これまでは医療機関内で閉じた世界で情報をお取り扱いだったと思うのですが、現在に至ってはそれぞれの医療機関同士もそうですし、クラウドというものも情報システムの中では利用環境としていい情報基盤もできてきていて、そういったものの利活用も視野に入れて、今までと全然違う形で情報システムを使うという形に変化してきております。一方で、医療機関さんの中にはそういった情報の取扱いに関して、特にセキュリティに関して専門特化した知識をお持ちでない職員の方が日々システムの運転をしているということもあって、新しい技術にキャッチアップしていくのがなかなか難しいというのは現実としてあるのではないかと見てとれます。
　それが結果として、残念なことに、昨今病院機関を狙った高度標的型攻撃と言いますが、ランサムウェアと言われる身代金を要求するような悪質なセキュリティのインシデントも発生しているという状況になっております。システムの利用環境が大きく変化しているというところをまずは出発点として御理解いただければと思います。
　次のページも同じようなことで、情報のシステムの環境自体も変わっているのですが、それに対して攻撃をしかけてくる人たちも徐々に雰囲気が変わっています。当初は、パーソナルコンピュータ、いわゆる昔の大きなホストコンピュータと言われるようなものから、スタンドアロン型の御家庭にも置けるような小さなもの、いわゆるパソコンとか、昔ですと大きなデスクトップのパソコンではあるのですけれども、家にも置けるようなサイズのいわゆるスタンドアロンと言われるようなスタイルのパソコンも出てきています。
　そういうものですと、まずは触ってみて、あ、こんなことができるのだということで、興味半分でいろんなソフトウエアをつくられて、それが結果として何がしかのインシデントを引き起こすというような故意ではなく偶発的に障害を引き起こすようなものも多かったのですが、だんだんインターネットの世界に入ってきまして、いろいろな人と情報、ネットワークが広がってきたときに、少し腕自慢といいますか、あそこの会社にネットワーク越しに入り込めたぞとか、あそこのホームページを書き換えてしまったとか、そういった形で自分の情報システムに係る知識をで試していく。あそこに入れたとか、あそこを書き換えたとか、そういう自己顕示欲を少し満たすような攻撃に変わっていって、今に至りますと、ランサムウェア、情報を人質に取ってお金を要求する。ある意味ビジネスとして成り立ってきてしまっているという現実がございます。
　それなりに収益も得られるということで、実は裏のネットワークの世界ではそういう人たちを専門にリクルーティングするような組織もあったりするという形で、かなり大規模に組織化されて、よく言われていますのは、国家機関としてそういうチームを持っているというようなレベルにもなってきていて、一つ一つの組織の中でこつこつと対策していくということ、日々の対策が非常に重要になってくるという側面も出て生きています。
　あとは、標準的にこういった形で守りましょうという大きな方針もつくって、個々個別の組織で対応していくこととあわせて、大きな方針に基づいて対策を打っていくという形で、全体の底上げをしていくというような必要も出てきている。
　そういった環境に対して、数年前から言われておりますのがゼロトラスト。ゼロトラストセキュリティと書きましたが、ゼロトラストネットワークという言葉も最近出ていますけれども、ネットワーク上に信頼できる環境というものが前提条件としてないと。皆さん、誰でもが通っている公道の中で暮らしている、情報をやり取りしているという感覚で、ここは安全ということではない形でのセキュリティ対策が求められているという状況になっております。
　昔ながらの環境の守り方としましては、波線のところが各組織の中の環境ということになりますけれども、ここの玄関、境界のところ、入り口を監視していくと。ここをしっかりゲートウェイとして守っていく。ファイアウォールという言葉を聞いたことがあると思うのですけれども、それからIPSという形で、通信の中身まで見るような対策とか、WAFと言われるウェブのアプリケーションを専門に監視するもの。要するに、ウェブアクセスをしているアプリケーションです。そういうものを監視するといった形で、境界の玄関のところを多重で見ていくというセキュリティ対策を打っていたのですが、最近、ここを通過してしまうような攻撃手法が出てきております。
　これに対しては、玄関の監視をきちんとするということをなくすということではないのですが、これも１つゲートとして設けつつ、中に入ってきてしまったものをなるべく組織の奥へ奥へと入っていかないように、ポイントポイントで監視をして、特に何かおかしいものがあるぞと言ったらそれを止める。レスポンス（対策する）までやるようなソフトウエアを入れて一つ一つの環境を監視していくという形で、組織の中もいろいろ悪い人が入ってきている、悪さをするソフトウエアが進入してきているということを前提に監視をしましょうという、セキュリティの監視のフォーメーションがだんだんと変わってきています。
　こういった形でセキュリティを守っていくということになりますと、これまでは境界の玄関のところを見ていればよかったのですけれども、いろいろモニターしなければいけないところが増えてくるということで、右下のほうに書かせていただいております監視をする人、それから専門の装置を置きまして、一番大切なのがログと言われるものの活用です。どんな人が出入りをしているかとか、各職員の方々が使っているパソコンの中に変なものが入ってきていないかというものを監視して、ないですよという形、またはちょっと怪しいものがありますよということを発見するためのログというものがあるのですが、それが膨大に発生するようになります。そうしますと、一つ一つのセキュリティ対策の製品から発生したログを人が見ながら、あ、これはおかしいかなということで監視していくのも大変ですので、SIEM（Security Information and Event Management）、こういった専門のツールを使ってログを一気に１か所に統合的に集めまして、それを分析してゆきます。このツールはリスクレートももちろんつけてくれますので、これは対処したほうがいいですよ、これはモニターしておくレベルで大丈夫ですよということをAIを使って振り分けをしてもらえるような、そういった監視の製品もございます。
　今はこういったものを取り入れて、人手では見逃しもあるといけないので、監視がし切れないこともあって、自動化をするようなシステムもございます。これまではどちらかというと組織の外にそういった専門の方にいていただいて見ていただいていたのが、組織の中にも入り込んでいただいて、ネットワークの監視を含めてセキュリティのインシデントを監視するという体制も置きながら、即時に対処する。何か事が起きてしまう前に、この専門家の人たちが見ていて、これは危ないですよということで、何らかの対策をすぐ打てる。予防的に対策を打っていけるような、こういったセキュリティのフォーメーションに徐々に変わりつつあります。
　特に今回の二次利用ということになってまいりますと、これまでは組織の中で管理していくというところだったのですけれども、二次利用基盤ということになりますと、様々な立場の方々がこのクラウドという環境を介して重要なNDBとか介護DBとか、こういった医療に関わる情報にアクセスをして、それぞれのお立場からデータマネージャの方であればデータのクレンジングをされたりするでしょうし、左端のところのデータベースそのものを運用している方であれば、このデータベースの稼動状況を監視されたり、それこそセキュリティのインシデントが起きていないかというところを監視されたり、またはクラウド。雲の絵になっていますけれども、この基盤自体を監視している人もいたり、それ以外に右側からまさに二次利用するという研究者の方々が何がしかの環境を利用して、仮想デスクトップと書かせていただいておりますが、利用できるような環境を設けて、そこを介して各データにアクセスしていくといった形で、いろいろな方々がロケーションもいろいろな箇所からアクセスするということになりますので、それぞれどういうお立場の方がどういう形でどこにアクセスしていくのかということを精緻に、丁寧にユースケースを分析して、誰がどこにアクセスしているのか、何の目的でどういった形でアクセスしているのかということを監視として確認していくということが必要になってまいります。
　昨今、クラウドサービスというのも私どもの情報処理推進機構のほうでも安全性の確認をして、安全性の確認が取れたものをISMAPという制度をもって登録する制度を運用しておりまして、確認が取れたものはそこに登録していただいて推奨すると。デジタル庁様のほうでもクラウド利用を推奨していらっしゃいますので、そういうことがさらに促進されるように、クラウド事業者さんというのもある程度一定の評価が進んできております。ただ、ISMAPという制度に登録されているからこれはそのまま使って大丈夫だということでは決してなくて、利用のシーンに合わせてそれぞれ情報のレベル感、機微情報を扱うのであれば、きちんと利用者側でもセキュリティ対策を取らなければいけないですし、適切な方がアクセスできるという環境を構築していく必要があります。
　クラウドサービスというのが、マネージドという言葉を使わせていただきますけれども、要するに、サービスを提供する側が全て管理してくれている、マネージドされた環境として提供されますので、利用者はもちろんそこに適切に自分たちの場所をつくって、自分たちの環境を整備して、そこを利用するわけですが、ここを使うメリットというのは、オンプレミスに自社でサーバーを買って、サーバーにOSとか利用に必要なアプリケーションを導入して、それをメンテナンスしていくわけですが、そこは自分で自己完結した世界で運用していけばいいのですが、マネージドサービスとなりますと、階層によっても違うのですけれども、基本的に使うときはそういった基盤上のハードウエアは買わなくていいですし、OSなどもあるものを使いましょうということであれば、そこの管理されたサービスを使っていくということになるのですが、ここをクラウド事業者さんがアップデートとかも全部やってくれるというのはメリットの一つでもあるのですけれども、設定がちょっと変わってしまったり、オンプレミスのときは自分たちでOSのアップデートもしますので、どこがどう設定が変わったかというのも確認できるのですが、クラウドの場合は管理を任せてしまっていますので、気がつかないときにアップデートが走ってしまって、我々が想定していた設定とちょっと変わってしまうということもなきにしもあらずですので、自分たちが設定した環境どおりに動いているかというところも含めて監視をしていく必要があるというところは、クラウドのいいところでもあるのですが、留意しながら使っていかなければいけないポイントかと思います。
　主に今回検討事項として話題に出ているところ、ざっとこんな形でしょうねというところをプロットしたものになります。安全管理措置は左側です。技術的な安全管理措置、物理的なもの、人的なもの。それから、この安全管理措置をきちんとつくることも大事なのですが、何かインシデントが起きたときにはきちんと緊急対応するといった緊急対応のルール、体制というのもきちんと整備する必要があるという点です。
　ログに関して言いますと、ログは当然ながら保管するということも非常に重要なのですが、発生した時点でとにかく活用する。ためるのも重要ですけれども、発生した時点で統合的な監視に活用して、何が起きているのだろうということは常にモニターするということが非常に重要になります。
　認証の方式は、二要素を使いましょうということが議論として上がっておりますけれども、アクセスする人ごとどういった方がどういう目的でアクセスするのかというところを丁寧に分析して、どなたにどういう権限を与えるのか、それからここにアクセスするときに身分を証明してもらう。私はきちんと許可をされた研究者ですとか、運用者ですということで身分を証明して、誰かということを証明することももちろんですが、その方がこの情報に本当にアクセスしていいのかというところで、情報アクセスへの認可というところのコントロールも必要になってまいりますので、認証だけではなくて、認可のコントロールというのも今後検討が必要になるかと思います。
　通信環境に関しましては一通り議論ができているのかなと思っているのですが、利便性を高めていくというところになりますと、費用面の考慮も必要になってまいりますので、当然セキュアにしていけばいくほど、安全であるということを担保すればするほど、それだけお金もかかりますので、今後はバランスを考えていく必要があるかなと考えております。
　認証方式です。これも技術的なところは別途細かく技術要件を検討する会がありましたら、そちらでと思うのですけれども、今、議論に上がっておりますのが、認証方式として二要素認証です。生体認証を御利用されるという方向性もお示しいただいておりますが、この認証方式の検討に当たっては、NISTというところが発表しております一つのガイドラインの中では、今、議論に出ていますのが真ん中の認証プロセスをどうやって認証していくかということで、単要素でいいのか。要するに、IDやパスワードだけでいいのか。それとも二要素を使うのか。かつ二要素というのは、生体認証であったり、何か強固なものを利用したらいいのか。このプロセスのところの議論がありますけれども、これ以外にも本人の確認方法の検討も必要です。自己申告をするだけでいいのかとか、もしくは対面、その場合リモートでもいいのですが、対面による確認が必要なのか、それとも、経済安保の関係で非常に強固なセキュリティ対策を打とうという方向性もあるようですが、対面で何等か資格を持った方が認証する、認可を下す責任者の方、有資格者の方が、この人は権限を付与して、大丈夫という面談の下に権限を与えることの検討もなされています。。こういった本人確認の方法も段階がありますので、この辺りももしかしたら議論があってもいいのかなと思っておる次第です。
　通信の暗号化です。ここは一通り議論が終わっているのかなと思うのですが、ちょっと申し上げますと、IPSecです。ガイドラインのほうでもIPSecを推奨として挙げられていらっしゃいますので、このような形のインターネットVPN、オープンなVPNと言うとちょっと語弊があるかもしれないですが、インターネットを利用したVPN。少なくとも下に書かせていただいておりますようなIP-VPNです。これは専用の事業者さんが提供する網になっておりまして、真ん中のところ、組織から組織の間をつないでいる網はいろんな人と共有はしているのですけれども、これは特定の事業者さんが提供しているサービスです。
　ただ、先月、外務省さんのほうでインシデントがあったというニュース、発表もございましたけれども、どうしてもIP-VPNなど通信環境が非常にセキュアなので、そこから先のところが監視とかセキュリティの意識から少し落ちてしまう可能性もあって、その外務省さんの件ももしかしたらそれかもしれないのですが、回線を過信してしまいますと、そこから先もしっかり監視をしていないと、もしくはセキュリティ対策をしていないと、ここが逆にセキュリティホールになってしまうということもあるということだけお伝えしておきたいと思います。
　特に二次利用のところで、冒頭にVisiting環境について御説明いただいたところであるのですが、岡村先生からも英国のGenomics Englandの事例を御紹介いただきましたが、英国においてもVisiting環境というもの。彼らはTRE（Trusted Research Environment）、リサーチ環境について提供しますよというサービスをしているのですが、英国の場合はAirlockという思想の下にデータのやり取りをしましょうということで、Visiting環境を構成しています。解析環境というのは貸出しの図書館ではなく閲覧の図書館であるべきと彼らはうたっております。要するに、図書館に行って本を貸し出してもらって、家に帰って読むということではなくて、ここにアクセスしたらそこの中で完結してくださいということが基本となっているようでございます。そうは言っても、この解析環境の中でデータを使って解析した結果は、一定の処理をすれば外に持ち出してもいいですよということにはなるのですけれども、必ず事前の承認が必要になるということになっています。
　ここに書かせていただいていますとおり、どこの人なのかということも当然示さなければいけない。IDを示さなければいけないですし、データをエクスポートする場合、どういうものを持ち出そうとしているかということをきちんと事前に明記し申請しなければいけないということになっております。
　インポートする場合、中に持ち込む場合には必ずウイルスチェック後のファイルを上げてください、かつ上げてきたものに関しては管理組織のほうでもきちんとチェックしますけれども、中に何かウイルスなどが入り込まないようにチェックをするということも厳密に行っていらっしゃいます。
　セキュリティの仕組みとしまして画面のコピーを貼らせていただいていますが、GoAnywhereというツールを使っています。これがいわゆるAirlock、環境をきちんと切り分けて使えるようにしていますよというところで、これを介してこういう形でデータが欲しいですという申請を上げて、そこからデータをダウンロードできるようにする。このステップを必ず踏んでくださいという形になっています。
　ここでNDBの環境とちょっと違うと思われるのが、Airlockという仕組みを使って申告はするのですけれども、データマネージャさんという方がまずチェックをして、ここでオーケーであれば、２日程度ですぐデータが出せます。ただ、そこでAirlockの審査が難しいとなると委員会に付託されるのですが、この委員会が非常に機動的に運用されていまして、申請の審査をする委員というのが６名いらっしゃいまして、６名の方がアサインされていて、担当が割り振られるらしいのです。その中の２名の方が審査をして、オーケーであれば許可と。ここで難しいとなると、データマネージャの方が申請者の方に対して、かくかくしかじかなので難しいから、このように変えてもらえれば出せますよということを御助言されていらっしゃるようです。いずれにしましても、ここに関して言いますと、非常に機動的に審査が行われていて、必ず集合した形で審査をしなければいけないということではないようでございます。
　時間もそろそろなので、まとめに入りたいと思いますけれども、安全管理措置としましては、基本的にガイドラインに書いていらっしゃるとおりのことなのかなということで、ここは割愛をさせていただきます。
　セキュリティの対策として、現時点でのセキュリティ対策というのは、これだけやっておけば絶対大丈夫というような担保が取れませんので、とにかくセキュリティは日々の活動を監視することが非常に重要です。セキュリティ対策製品も導入しているだけですとか、あとは導入してコンソールからずっと見ているだけという形にならないように、どういうものがアラートとして発報されたら、どういう形で対処するのかというところまで対処の方法のところの検討と運用が重要です。それからアラートが上がったときにどのレベルのものであれば対処するのかというリスクレートもきちんと判定して対策を打つルールを講じていくということ。こちらが非常に重要になってきます。
　ログは保管というよりも活用して何ぼというところです。ここはぜひ御理解いただければと思います。
　セキュリティ対策の基本としまして取りまとめをさせていただきます。本当にいつ何か起きてもおかしくないぐらい今、いろいろなものが世の中に蔓延してしまっておりますので、日常的な監視を常に怠らないようにしたいというところです。不審な挙動には早期に気がついて、何かある前に極力被害の局所化が可能なアクションをしていく、未然に防止するということが非常に大事です。
　また何か起きてしまったときに組織的にタイムリーに活動ができるように、どういう手順で誰がやるのかの規定も重要です。「CSIRT」という言葉はガイドラインの第６版には入ってきておりましたが、CSIRTというものを設置し、インシデントが発生した際にはきちんとタイムリーに対応していくということが非常に重要になってまいります。
　費用対効果ということはよく言葉にありますけれども、何か投資をするときに、セキュリティ対策というのが何もない状態が一番ベストなのです。要するに、これだけ費用をかけたので何も起きませんでしたという説明をしていかなければいけなくて、経営者の方にセキュリティ対策費用の確保というのは御理解いただきにくいのですけれども、でも、必ず必要なものですので、なるべく対策を打っていく。冒頭ちょっと申し上げましたとおり、アセスメント、どこに何を置くのかというところも丁寧に設計をしていく必要があるという点が重要です。
　もう一つポイントは人手をなるべく減らしていく。自動化とか、AIの活用をもって対策をしていくというところも人手を減らしていってコストバランスを取っていく。
　事が起きないのが一番安心な状態ですので、この環境などを利用する人には啓発活動を行って、かくかくしかじかの方法で必ず使ってくださいということで、啓発活動をしていくということも大事になるかと思います。
　最後に、ITはあくまでも道具、ツールでしかありませんので、いろいろ運用のルールとか規定類、こういったものの整備も並行して非常に大事になってまいります。この点も言及しておきたいと思います。
　時間を超過してしまいまして失礼しました。ありがとうございます。
○小笠原主査　田辺構成員、ありがとうございました。
　とても勉強になります。７枚目のパワーポイントが特に重要かなと思って聞いておりました。
　それでは、３人目、足立構成員から資料２－４の御説明をお願いいたします。
○足立構成員　それでは、足立のほうから基本的に民間データベースの現状というところを少し御紹介した上で、今回の公的データベースとの連携という観点で少し確認したい点等をこちらのほうで説明をさせていただければと思います。
　今回の構成員の中では唯一民間というところで、私は医療データベース協会というところから来ているのですが、医療データベース協会自体は、民間の医療データのデータベースを商用あるいは学術のほうで提供している事業者の集まりになっています。いわゆる業界団体というよりは、もともと医療データという機微な情報を取り扱うというところに特色がありますので、そこについて社会的な信頼を得るというところで、信任の確保のために設立された団体になっておりまして、個人情報保護法上の認定個人情報保護団体としての認定も受けている団体になります。
　民間の医療データベースというのは、公的データベースもそれぞれに対応したデータベースがございますが、おおむねデータソースとしては３つございます。１つは医療機関由来。もう一つが保険者。いわゆるPayerと言われる人たちの由来。あとは保険薬局由来というところでございまして、当然ながら医療機関のデータといったものについては、いわゆるアウトカムデータ、実際の医療行為や処方に関する結果というデータを含むタイプのものは、医療機関由来データの中にだけ存在しているというところでございます。
　保険者由来に関しましては、基本的にはレセプト、あるいは健診データという形で検査値といったようなデータが入ってくるものになります。保険薬局については、基本的にはレセプトデータというものが中心になってくるというところで、どこから来るデータかということによって大分データの属性も変わってくるというところでございます。
　次に民間データ自体の法的な性質というところですが、基本的に今の民間の医療データベースというのは、法律については個人情報保護法が原則的な法律というところになりますので、これを商用のデータベースとして提供するという限りは、匿名加工情報のデータベースという形で提供されているものになっております。
　今回次世代医療基盤法上の民間データベースとの連携というところで、こちらは次世代医療基盤法上、特別な手当てがされているので、いわゆる名寄せが可能な匿名加工医療情報というもの、あるいは仮名加工医療情報といったものが用意されているわけですが、今のところ認定されている３スキーム全て、実際に加工の業務を担っている会社は民間企業なのですが、作成事業者自体が営利企業が実施しているという例は現状はないという形になっております。
　早速データ品質の考え方ですが、データ品質の考え方というのはもちろんいろいろあるのですが、医療データに限らず、一般的にデータの品質管理プロセスというところについては、国際的な標準規格としてISO/TSの8000というものがございまして、プロセス全体についてきちんと品質管理のPDCAサイクルを回しましょうということになっております。
　特に医療データの場合の用途というところで、レギュラトリー領域というところで活用するということになりますと、特にプロセスに関するデータ特性。実際にデータのトレーサービリティーのところをどのように確保するかというところも、一連のプロセスの中では重要なものになっております。このプロセス自体は、データを提供する、データが実際に生成されて、その情報をデータとして固定する人たちと、実際にデータを集めてデータベースとして構築する人と、そのデータを利用する人というところで、それぞれレイヤーによって担うべきロールというところが変わってくるので、実際この辺の責任分界をどういうふうに設計するかというのが、品質管理との関係では結構重要になってくると考えております。
　次にデータ自体の品質というところですが、データ自体の品質に関しても標準規格がございまして、ISOの25012というところでは15種の品質特性がございます。個別に15個を御紹介するのは避けますが、実際のところ、まずどんなデータであったとしても通常備えておくべき特性として、基礎的な品質特性としては一番上の３つです。正確性、完全性、一貫性というところは基礎的で、必ず確保されるべき性質というところで、こちらは非常に重要視されているところでございます。
　残りの12個は付加的な品質特性というところで、別に付加的だから持っていなければいいとか、持っていなくても構わないとか、そういったものではないのですが、例えば最新性というのは、更新がどのくらいのタイミングで行われているかという情報ですとか、効率性というのは、実際にデータを解析にするに当たって効率的に行うためにコードの割当て等がされているかどうかといったところですが、こういったいわゆる使い勝手に関するような付加価値というところが、実際の商業データベースの領域においては市場競争が行われていて、付加価値という形で価格に転嫁されている領域になってまいります。
　品質特性のうち、どのようなプレーヤーであっても共通の利益としてくくり出しやすい部分については、基礎的品質特性とアクセシビリティや追跡可能性に関する部分になります。このようなものは、事後の工程、実際にデータを加工する過程では、もはやデータ欠損が回復できなかったりする部分であるとか、あるいは単純な置換作業等でそれ自体が、いわゆる使い勝手という点で言うと事業者間によって差が出づらい部分、こういった部分についてはみんなの利益のために共通化していくという部分については異論が出づらい部分ですので、こういった上流工程で担保されるべきもの。上流工程というのはそもそも情報をデータとして固定する医療機関現場というところも含みますが、こういったところの品質特性については上流で担保されることが強く期待されると考えております。
　一方、使い勝手という部分で効率性や可用性といった付加的な品質特性というのは、実際どのような頻度でどの規模で、どういった目的でデータを利用されるかというところが、実際にデータを利用される方。民間市場の場合は「需要者」という言い方になりますが、需要者によって異なってくるので、効率性や可用性の確保にどの程度の工数やコストをかけるのかといったところは、基本的には各データベース事業者においてターゲットとしているお客様に応じて競争している領域になってくるので、かつこの辺りは実際に使われる利用者によって要求しているプロセスの種類も非常に多くて、複雑というところもありますので、こういった部分についてまで公的な枠組みの中で確保しようとするのは適切ではないだろうと考えております。
　もう一つ、標準化というものを考えていきましょうというところが今回分科会でも議論になっているところかと思いますが、標準適合性というところも、結局のところ需要者側によって適合すべき基準の範囲が異なってくるというところがありまして、特に時系列的にマスタ自体が変化していくタイプのデータについて、どこまできちんと統一的に追っかけることができる標準適合性を担保するかというところは、これの費用とトレードオフになってくる部分がありますので、想定する需要者といったところを確定していただいて、どこまでを公的なものが担って、どこからは民間に委ねるのかというところを議論していただく必要があるかなと思っております。
　私自身も協会加盟の一企業で通常は仕事をしているのですが、クレンジングやコード化、標準化というところの実際例を少し御紹介します。取込データの最初のバリデーションとかクレンジングといったところ、あるいは検査値や投与単位等の学会公式基準等への変換みたいなものをまず最初に実施をしています。
　あとは、これはレセプトとかのマスタとかでよくありますが、その他のＸ系のデータのコード化といったところの最初期の段階で行っております。
　コードマッチしない項目のコード化というところは、各社によってアプローチが異なっておりまして、各社が経験的に蓄積している辞書をメンテナンスしていて、これによってコード化をしているという場合もあれば、最近の場合ですと、NLP、自然言語処理に基づいてコード化を実施しているタイプの事業者さんもありまして、この辺のアプローチに関しては単一解がないというところになっております。
　次に、マスタのメンテナンスというところなのですが、標準適合性といったところは、お客さん、特に弊社の場合は、最初清水先生のほうに高かろう良かろうというふうに御紹介いただくのが民間業界のデータベースというところで、この辺りは各マスタも更新頻度が非常に高くて、月１回以上、ともすれば月に２～３回メンテナンスしているタイプのマスタといったものもございます。こういったものについては結局、更新の都度メンテナンスが必要になっているというところで、かつ過去の情報は過去のマスタに基づいて整理されているので、過去分との整合的な解析を確保するためのマスタのメンテナンスというのにはかなりの工数がかかっているというところになっておりまして、全体の工数としては通常3,000ステップ前後、私の所属企業の場合にはかかっているといったところで、使い勝手を本当に追求してしまうと、これぐらい工数がかかってしまいますよという状況になっております。
　結局、品質確保についてどこまで官民協調してやっていくかというところですけれども、繰り返しになりますが、上流でなければ担保できない特性といったものについては、課題感をしっかり共有した上で、商用・学術利用問わずに求められる基準の標準化といったところについては進めていっていただければと思っております。
　一方、使い勝手という部分での標準適合性等のメンテナンス作業といったものは相当に煩雑でして、特に時系列にどこまでも追っかける部分といったところですとか、あとは需要者ごとのニーズに応じたようなメンテナンスみたいな部分については、各社それなりにコストをかけて知的財産として創生しているという部分がありますので、こういったものについてある程度業界を問わず共用基盤として実際にやっていくという話なのであれば、これは既に通信規格とかそういった国際規格のところで、例えばIEEEとか、ああいうところの5Gとか4Gという規格だったりとかでも採用されているFRANDという考え方がありますが、これはいわゆる公平で合理的かつ被差別的な契約条件で実際のステークホルダー全体の利益のために、IPといったものをコンソーシアムであるとかコミュニティーに対して供与するという仕組みですが、こういったものを使うことによって、実際マスタメンテナンスとかそういったところについて相当資本を投下している会社が、そのIPを全体利益のために供与するといったところについての資本回収の機会をきちんと確保した上で、慎重に進めていくということが重要であると考えております。
　この辺りは結構マルチステークホルダーで、必ずしもこの技術分科会の中で議論し尽くせない部分もあると思っておりますので、こういったところについて、実際のHowの細かい部分、どの部分についてどういうマスタにしましょうかという部分については、官民で連携したようなコンソーシアム等を確保した上で、積極的に創出をしていく。先ほどほかの先生からも御指摘がありましたが、国際的な規格化や標準化といったところも含めた上で議論を進めていくことが必要ではないかなと考えております。
　こちらは時間も少ないので読み上げませんが、実際これからセキュリティも含めて技術的側面を議論する上で、親である分科会のほうでも議論していただくというところでちょっと決めておいていただかなければなと思っている点があります。例えばデータプライバシーと言うと、基本的に関連するところでは、匿名加工、仮名加工の基準をどういうふうに技術的に設定するかというところがあるかと思いますが、結局、この辺りも攻撃者想定、どういうタイプの攻撃者を想定して本人が再識別されるリスクを考えるのかというところがきちんと設定されないと、技術的な水準のセットアップが難しいというところもありますし、標準作業自体も標準適合性を確保、どのステップでやるかによっても、アウトプットの仮名・匿名の確保をするステップが、前処理で入るのか、後処理で入るのかが変わってしまうので、どのくらいアドホックな解析者のニーズに応ずるかというところも結構しっかり意思決定をしていただいたほうがいいのかなと思っております。
　あと、本人関与が親の分科会のほうで議論されておりますが、技術的な観点で言うと、いわゆるオプトアウトフラグであるとか随時死亡情報が連携されないと、本人関与の機会がデータベースに対する取り込み時点であったかどうかの機械的な判定というものができなくなってしまうので、本人関与というのを取り込むという話なのであれば、自動的に技術的な基盤としては、死亡情報の取り込みをデータベース基盤としてどういうふうに行うかというところの設計が必須になってきますので、こういったところもしっかり親会のほうで議論いただければなと思っております。　民間データベースとの連携というところですが、次世代医療基盤法はともかく、次世代医療基盤法以外の現在主流の商用の民間データベースといったものは、個人情報保護法上の匿名加工情報が基礎になっております。これらの情報を作成しているのは、データベース事業者ではなくて、あくまでも情報がデータに固定されるタイミングである医療機関とか保険者という方になっているので、実際の被保険者番号等を保持した状態で商用データベースに供与してくださいというのは、現行法上は難しいところがございますし、仮に次世代医療基盤法同様の改正があったとしても、こういったところについては必ずしも十分な量が供給されないかなというところを少し懸念しております。
　そういったところも含めていろいろ御議論いただければなと思っております。
　以上です。
○小笠原主査　ありがとうございます。
　それでは、残り時間15分と少なくなりましたが、質疑応答に入りたいと思います。皆様方、いかがでしょうか。清水構成員、お願いします。
○
清水構成員　清水です。今日初めて発言させていただきます。
　コメント及び提案が３点あります。
　まず１点目。今日お二人の先生にセキュリティに関して体系的にお話をしていただいたので大変クリアになり、私なりに随分理解が進んだと思います。その中でちょっと気になった点があります。先ほど３段階あって、スタンドアロンという時代から、今クラウドという時代になっているというお話の中で、私、今まだNDBの解析を継続していて最終段階に入っているのですけれども、私が申請した時点ではHICというのがなかったので、スタンドアロンでタコ部屋という形でやっています。
　これがクラウドになるということによって使い勝手がよくなるのを期待したいところなのですが、技術的にもいろいろリスクが高まる中で、要件を厳しくしすぎてしまい、使い勝手とのバランスがまた悪くなってしまうということをちょっと懸念しています。使い勝手とセキュリティ、安全性のバランスをどこに取るかということを念頭に置かないと、危ないからどんどん厳しくしていくという方向に行くのはちょっと避けたいなと感じています。
　どこでその使い勝手等を切るかというところですけれども、私、前回お話しさせていただきましたが、ユーザーそのものに悪意がある場合、これを防ごうとすると相当いろいろな対策をやらないといけなくなってしまうので、ユーザーに対しては罰則を設けることによって、例えば宣誓書を書かせることによって悪意はないという前提に立つ、一方で、外部からのハッカーや悪意ある第三者、そういう人に対するリスクに対する点でバランスを取るところに置いていただけたらなと思いましたので、一言コメントさせていただきます。
　２点目はマスタの話。どのマスタを対象にしていくか。私は前回施設マスタを加えていただきたいということを申し上げたのですが、議事録というか、サマリーの中には、時系列で取るというお話は出ていたのですけれども、施設マスタの話が載っていなかったので、もう一度付け加えさせていただきたい。
　マスタの中の幾つかは厚生労働省さんがもともと持っている情報です。高かろう良かろうの民間の業者さんは、そういうところから手に入れて、何百工程、何千工程を経て常にアップデートしているという状況です。厚生労働省さんの場合には、その元データを持っているお立場なので、やる気になればアップデートも一般の方よりは相当やりやすいのではないかなと思うので、マスタに関してその辺りをちょっと付け加えさせていただきました。
　最後ですけれども、これも前回お話しさせていただいたのですが、セキュリティという話をしたときに、Visiting環境の中であったり、ホストの中にあったりというデータ自体についてはよく出るのですが、これを外部に開示する公表許可を得た結果のものに対するセキュリティの考え方があります。これに関してはNDBでは最小集計単位という概念があって、何でもかんでも10未満の集計結果はいけないという形になっていて、これが多くの場合、あまり意味がないというのと同時に、審査のほうでも非常な手間になっていると思います。
　なので、解析環境の外に出す、一般公開していい内容に関する考え方についても、今回検討するセキュリティの概念の中に一つ加えていただけたらなと思って、ちょっと付け加えさせていただきました。
　以上、３点です。よろしくお願いします。
○小笠原主査　ありがとうございます。清水先生、お返事をもらったほうがいいですか。コメントでよろしいですか。
○清水構成員　議事録に残ればそれで大丈夫です。
○小笠原主査　事務局、いかがでしょうか。
○企画官　事務局でございます。
　清水先生、コメントありがとうございました。
　前回御説明いただいた施設マスタのところは資料１に反映できておらず、失礼いたしました。先生から御提案のあった医療機関マスタの全国版が必要というところもぜひ付け加えておきたいと思います。その上で、また親会のワーキングにもしっかりと御報告をさせていただきたいと思います。
　残りの２点についても御指摘を踏まえて、また御議論を進めていければと思っております。よろしくお願いします。
○清水構成員　ありがとうございます。
○小笠原主査　山口構成員、お願いします。
○山口構成員　ありがとうございます。
　コメントです。本日、事務局の皆さんに説明いただきたいわけではなくて、今後、議論していただければと思います。
　内閣府から次世代医療基盤法のVisiting環境についてご説明いただきました。また、田辺構成員からセキュリティ全般についてご説明いただき、よく理解できました。田辺構成員が言及されるように、システムに委ねなければならない部分もありますが、システムだけで全て賄えないことから、システムでできることはシステムで実現し、それ以外はルールとか契約で縛るべきということが重要であると理解いたしました。本件については既に資料にも示されていますが、特に重要だと思います。全てをシステムで実現させようとするとコストに跳ねるだけなので、特に留意したほうがいいかなと思いました。
また、Visiting環境における作業部屋についてコメントさせていただきます。清水構成員からいつも「タコ部屋」という表現でご説明いただいておりますが、特別な要件を課した部屋を設置させることは避けたほうがよいと思います。利用中だけ関係者で専有使用するようにしてくださいとか、会社内で他の人が閲覧させないための要件を定め、その要件を遵守して使ってくださいぐらいにするのがいいのかなと思います。よろしくお願いします。
　以上です。
○小笠原主査　山口構成員のはコメントということで、事務局の皆さん、よろしくお願いいたします。
　岡田構成員、どうぞよろしくお願いします。
○岡田構成員　ありがとうございます。
　岡村構成員の御発表に関連して１つ御質問と意見がございます。１つには、岡村先生にJLACのことに言及いただきまして、重要な情報、御指摘もいただいて、大変ありがとうございます。JLACセンターというところではJLAC11、10共に全面公開していく方向で、大変な関係者が今、尽力されているところでございます。それは１つ御報告でございます。
　岡村先生からOMOPについてのお話がございましたけれども、先生、FHIRのほうも非常に熱心に研究で取り組まれておられて、FHIRですと、Terminology ServerあるいはTerminology Serviceというところで、各国、非常に強く利用しているというか、推進しているところだと思うのです。特に英国、NHS Digitalなどもかなり進めているところだと思います。
　実は各国のTerminology ServiceとかOMOPの考え方も割と今、方向性が共通しているところがあって、上位にconcept IDであったり、識別子があって、それに対してローカルなコードであったり、あるいは自国内の標準コードをマップするという考え方が割と広がっているのかなと。国内でもぜひそういう方向をちょっと考えていかないのではないかなとずっと思ってきたところですが、その場合、恐らく国際標準との、国内がガラパゴスにならないように対応づけを可能にしていく方向性の検討とともに、それから国内の複数のコードのマッピングみたいなものもサービスしていくというのは、恐らく共通の枠組みになっていくのではないかなと感じております。
　お聞きしたいところが、OMOPの御経験で、国内のコードをOMOPを御利用になられるときに国際のコード、概念にマップする辺りは御経験がおありか、そのときの難易度、ハードル、その辺、もし感触が分かったら教えていただきたいのですが、いかがでございましょうか。
○岡村構成員　岡田先生、ありがとうございます。
　私も具体的に何かの事例でOMOP変換したという経験はなく、丁度今そういう取組に着手し始めたというところです。実際にどの標準コードを使うべきかを調査する中で、例えばSNOMEDを使う場合、OMOPでSNOMEDを使う場合はライセンス上の問題はないのですが、OMOP以外と連携する場合においてもSNOMEDを転用する場合にライセンス上の要件が生じるのかなど、ライセンスの詳細をクリアにする必要があるだろうと思っています。また、日本にそもそも普及している標準コードがないような、例えば解剖学的な体の部位のマスタとかは恐らく日本で普及したものはないと思うのですが、そういうものについては、できるだけ最初から国際標準コードをつけてしまうという考え方はどうだろうと、ちょうど調査をしながら考えているところです。
○岡田構成員　そうなのですね。ぜひまた御教授ください。
　先生が最後のほうにおっしゃった国内にない標準、そこを掘り下げて具体的提案をしていくところもこの二次利用のところではとても重要ではないかなと思いました。
　ありがとうございます。また引き続きよろしくお願いします。
○岡村構成員　よろしくお願いします。ありがとうございます。
○岡田構成員　あと一個だけ手短に。
○小笠原主査　どうぞ。
○岡田構成員　これは最後の御講演のところで足立構成員からお話。まさにここなのですけれども、FRANDという考え方を御指導いただきまして、大変ありがとうございます。実は医療情報標準でこういう課題がありまして、民間事業者が相当の資本を投下して開発してくるような知財に相当するところ、それを共通に利用したいというときに、一体これをどういうふうに整理していくのがいいのかという課題がございます。
　例えば公的な標準規格にするときに、民間事業者がIPを有しているというときの考え方みたいなものがございますでしょうか。手短に教えていただけましたらと思いますが。すみません。
○足立構成員　ありがとうございます。足立でございます。
　幾つか考え方があって、規格している団体によって、規格策定のどの段階で、要は、IPを規格に組み込まれようとしているものについて持っているかというものについては、手を挙げるということに関しては、３団体ぐらい可能。IEEEをはじめとして、いわゆる国際標準規格団体と言われるものについてはプロセスルールを設けておりまして、それに基づいて、通常は規格を詰める中で、この規格を組み込みたいのですけれどもと言ったときに、御社が持っていますよねと言われるパターンもあれば、IPを持っているところが自社のデータを積極的に使ってもらいたいから、逆に積極的に規格に組み込んでいきたいというモチベーションの場合もありますが、いずれにせよ規格に組み込まれてしまった後に知財を持っていますと言って手を挙げるのは禁止されているとか、幾つかルールがあるのです。なので、この辺は規格の策定に関与するグループをつくるときに、あらかじめそういう契約をして入るという仕組みになっています。
○岡田構成員　ありがとうございます。調べます。ありがとうございました。
○小笠原主査　ありがとうございます。
　それでは、ちょうど時間になりました。最後、私からコメントなのですが、標準につきまして国際標準規格の話が出ておりましたが、我が国にHELICS標準というのがあるかと思います。HELICSで標準規格を決めた上で、それが自動的に厚生労働標準に準拠されていると思います。たしかHELICS標準は、ISOなどと整合性をとっているはずなので、この点を確認したほうが良いかなと思いました。
　あと、Genomics Englandの話とかを伺っていながら、結構人が関わっていると感じており、これが日本でどこまでできるのかわかりません。特に専門家の育成ですが、私どもの委員会では関わるものではありませんが、どのように育成するかがちょっと気になりました。
　今後臨床応用を進める、またセキュリティを上げるということと費用対効果なども踏まえて次回以降の議論を進めていきたいなと考えている次第です。
　それでは、時間も過ぎましたので御質問等ありましたら、次回以降、ぜひ積極的な議論を進めていければと思っております。よろしくお願いいたします。
　最後に、全体を通じて何か御意見ございますか。
　では、本日の議題は以上で終了させていただきます。
　それでは、議事を事務局にお返しいたします。どうぞよろしくお願いします。
○室長補佐（岡）　小笠原先生、ありがとうございます。
　構成員の皆様、本日も活発な御議論をいただきましてありがとうございました。
　次回の開催は、事務局から御案内をさせていただきます。
　本日の議事録につきましては、作成次第、御発言者の皆様方に御確認いただきました上で公開をさせていただきますので、よろしくお願いいたします。
　本日冒頭での岡田先生の御質問や、議論の中でもございましたけれども、今後議論の一定のまとめも行いながら、今回初発の論点も多々いただいたところでございますので、そちらのほうを整理させていただいて、春以降、継続した議論ができればと思っております。一方で、先生方のプレゼンが一巡したところでございますので、次回の技術作業班で一定の意見の集約をさせていただければというふうにも思っておる次第でございます。
　そして、今後開催予定の医療等情報の二次利用に関するワーキンググループのほうで技術作業班の議論の報告も求められているところでございますので、次回のワーキングにおきまして現在の議論内容として報告をさせていただければと思っております。
　事務局からは以上でございます。
○小笠原主査　それでは、以上をもちまして本日の部会を閉会させていただきます。活発な御議論ありがとうございました。
一同：ありがとうございました。
――　了　――