- ホーム >
- 政策について >
- 審議会・研究会等 >
- 医政局が実施する検討会等 >
- 第３回健康・医療・介護情報利活用検討会医療情報ネットワークの基盤に関するWG議事録
第３回健康・医療・介護情報利活用検討会医療情報ネットワークの基盤に関するWG議事録
日時
令和４年１月７日（金）１５：００～１７：００
場所
Web開催
（事務局のみAP虎ノ門Dルーム）
（事務局のみAP虎ノ門Dルーム）
出席者
- 構成員（五十音順、敬称略）
- 高倉 弘喜
中島 直樹（主査）
松村 泰志
宮田 裕章
議題
- (1)標準規格準拠の電子カルテ導入の推進策について
- (2)関係者からのヒアリング
- ①PHR サービスとEHR の連携の実状について
- ②医療情報システム開発センター(MEDIS)での標準規格の維持管理 について
- ③HL7 FHIR の現状と社会実装イメージ について
- ④標準電子カルテの検討にあたって技術やセキュリティ対策の選択と集中について
- (3)その他
議事
- 議事内容
- ○島井補佐 お待たせいたしました。定刻となりましたので、ただいまより、第3回医療情報ネットワークの基盤に関するワーキンググループを開会いたします。構成員の皆様におかれましては、大変お忙しい中、本ワーキンググループに御出席くださいまして、誠にありがとうございます。本日は新型コロナウィルス感染症対策の観点から、オンラインによる開催とし、報道機関や傍聴希望者に関しては、事前に御案内いたしましたYouTubeから傍聴しております。なお、会議中、御発言の際は、手を挙げるボタンをクリックいただき、中島主査の指名を受けてからマイクのミュートを解除し、御発言のほど、よろしくお願いいたします。なお、御発言終了後は、再度マイクをミュートにしてくださいますよう、お願いいたします。
次に、本日の構成員の出欠状況について申し上げます。本日は、宍戸構成員、松田構成員より御欠席の御連絡を頂いております。また、長島構成員より、急きょ、急務のため御欠席されるとの御連絡も賜りました。つきましては、本日の議事の2.関係者からのヒアリング①PHRサービスとEHRの連携の実状についてに関しましては、また改めて御説明を頂く御予定といたします。
それでは、資料の確認をさせていただきます。資料は、議事次第、資料1、資料2-1～2-4及び参考資料1～5を事前にメールで送付させていただいております。Web会議の画面上、見にくい点等ございましたら、当該資料をお手元で御覧ください。事務局からは以上となります。
それでは、以降の議事進行につきまして、中島主査、よろしくお願いします。
○中島主査 それでは、よろしくお願いします。早速始めたいと思いますが、議事（1）標準規格準拠の電子カルテ導入の推進策について、事務局から説明をお願いします。
○田中室長 事務局です。資料1、標準規格準拠の電子カルテ導入の推進策を御覧ください。1枚めくっていただいて、第1回の会議でもお示ししておりますが、平成23年、平成26年、平成29年の電子カルテの導入状況です。（未導入）という欄を一番下に作っておりまして、現在このような未導入の割合になっております。中小規模400床未満の医療機関における電子カルテの普及は、大規模の医療機関ほど進んでいないという現状です。全国的に医療機関間で電子カルテ情報の共有・交換ができる標準規格準拠の電子カルテを導入することが、当然全国的な基盤を作る際には、併せて対策をしていく必要があると考えております。これを普及するためには、標準規格準拠（HL7 FHIR規格でのデータ・情報の交換ができる）の電子カルテを普及し、この電子カルテのメリットを踏まえて、コストの負担を削減することを進めていかないといけないと考えております。
では、実際に3ページに、この標準規格準拠の電子カルテ導入のコストを下げ、新しい文書などをアップデートする際に、安価に必要最低限の補修などで、文書などを拡張していける拡張性を担保しながら、コストを下げるためにはどんなことが必要かを記載しております。1つ目は、標準規格準拠への対応を、電子カルテの基本共通機能として実装すること。そして、標準規格の更新や拡充に応じて、電子カルテの基本共通機能をパッケージとして、更新機能を拡張することで、コストを下げることが可能になると考えております。また、標準規格準拠の電子カルテの導入で、当該電子カルテの基本共通機能が随時更新機能を拡張されることを踏まえ、当該機能への医療機関独自のカスタマイズを避ける。この独自のカスタマイズを行うことで、これに必要な改変費用、並びに以降の基本共通機能の更新等にかかる費用を負担することが出てくるので、こういったカスタマイズを避けることなどもコスト低減、拡張性の担保には必要ではないかということです。
4ページに実際にこの標準規格準拠への更新費や、電子カルテの導入費などを、どのように支援するかということで、以前から申し上げております医療情報化支援基金の活用を検討しております。先ほどの電子カルテの導入状況などを踏まえ、中小規模医療機関を対象として既に電子カルテが稼働している医療機関においては、標準規格準拠の電子カルテへの更新にかかる費用の一部、電子カルテが未導入の医療機関においては、標準規格準拠の電子カルテの導入にかかる費用の一部を、以下に書いてあるような要件の案を要件として、支援をしてはどうかという記載をしております。
まず、①として、標準電子カルテの基本共通機能として、HL7 FHIR規格に準拠した文書、今、HELICS協議会で審議中ですが、診療情報提供書、退院時サマリー、健診結果報告書のデータの入出力ができること。②として、HL7 FHIR規格に準拠した文書のデータ出力時に含まれる医療情報（傷病名、検査、処方）には、厚労省標準規格等のコードやマスターを付与すること。これは、前回、前前回の中でも先生方からも御意見を頂いた内容になっているところです。
また、本当にこれらの要件を満たしているかどうかという確認の手段として、例として、③HL7 FHIR規格に準拠した文書・医療情報の出力データサンプル並びにデータ送受信経路のネットワーク構成図を提出することなどを、要件に入れてはどうかという記載をしております。
そして、前回、委員の先生から御指摘がありましたが、やはりこの費用をどのように負担をしていくかという中には、現在、診療報酬の算定項目の中には、既にこのような電子化を評価する算定項目があります。この現状の診療報酬の算定項目を踏まえて、既存の算定要件の変更等を検討して、こういったコストの負担や、患者の目線から見て、どのように費用を考えていくのかを検討してはどうかということを記載しております。
また、先生方から現在の診療報酬の算定項目を説明してほしいという御要望を頂いておりましたので、このあと、実際に今ある算定報酬の項目について、担当の保険局のほうから御説明をさせていただきます。金光補佐、よろしくお願いいたします。
○金光補佐 保険局医療課です。資料の5ページから、診療報酬の関係で御用意しております。診療情報に関して全てを網羅するというのはなかなか難しいところもありますので、主立ったところについて5ページ以降で御準備させていただいているところです。1つは、診療録管理体制加算ということで、こちらは御紹介です。適切な診療記録の管理を行っている体制というものを評価し、現に患者に対しきちんと診療情報を提供している、そういう体制を有している保険医療機関に対し、診療報酬としての評価をしているというものです。ここに加算ルールを書いていますが、きちんと診療録の管理をし、そのための規定を設け、さらには人員を配置している、こういったことを医療機関に求めて、それに対する診療報酬上の評価をしております。
次のスライドをお願いいたします。併せて、診療情報のやり取りというところです。先ほどもHL7 FHIRについての御示唆がありましたが、診療情報提供料というものがあります。これは、医療機関間の連携とか、医療機関と他の機関との連携、ここに診療情報のやり取りというものが発生するものですので、ここについて患者1人につき月1回という算定の上限ですが、250点2,500円の診療報酬として設定しています。ここに①から⑦まで様々な状況について記載しておりますが、先ほど申し上げたとおり医療機関だけではなくて、保険薬局とか、さらには学校、そういったところについても診療情報をやり取りするといった場面を想定して、診療報酬上の評価を設けているところです。
次のスライドをお願いします。これまでも診療報酬においては、やり取りについて電子的なやり取りの普及というところも見据えながら診療報酬の評価を設けてきたところです。こちらは平成28年の診療報酬改定で行ったものです。電子的に送受できることをきちんと明確化させていただくとともに、画像情報や検査結果等の電子的な送受に関する評価というものを設けて、こちらはこの時点の芯というものですけれども、検査・画像情報提供加算、診療情報提供料を算定するに当たって、退院患者の場合、その他の患者の場合いずれも設けておりますが、画像情報とか検査結果等を電子的方法により提供した場合に算定できる。そして、診療情報提供書を受け取って実際に診療に活用するといった場面も想定されることですので、それに対して電子的診療情報評価料という形で送り側、受け手側いずれに対しても診療報酬上、評価を作っているところです。その際には、施設基準の所、下に書いていますが、患者の医療情報に関する電子的な送受信というものが可能なネットワークをきちんと構築していただくということですし、標準的な方法により安全に情報の共有を行う体制というものの具備を求めているところです。
次のスライドをお願いします。細かい要件を書いていますが、一番下の所、施設基準等という所です。先ほども主立った所は御説明させていただきましたが、厚生労働省医療情報システムの安全管理に関するガイドラインを遵守するということで、これを根っこにして施設基準を立てているところですし、下から2つ目のポツですけれども、厚生労働省標準規格に基づく標準化されたストレージ機能を有する情報蓄積環境を確保することというところを設けております。診療報酬での評価に当たっては、こういった実際のインフラの整備をできるだけ反映しながら、診療報酬の構造を作っていくというところかと思いますので、医政局での御議論も踏まえながら、少なくとも令和4年の改定に向けてできることについて、一つ一つ取り組んでまいりたいと考えております。私からの説明は以上です。
○田中室長 資料1について事務局からの説明は以上です。
○中島主査 ただいまの御説明に対して、構成員の方々から何か御質問、御意見はありませんか。課題は大きく2つあると思うのです。1つは、まだカルテの電子化が50％にも達していないということです。もう1つは、HL7 FHIRがようやく出来たところで、今から普及ということなので、この標準規格をできるだけたくさんの医療機関に普及させるためには、カルテの電子化と標準規格の普及を両方一度にやらなければいけないということが大きな課題だったと思います。それで、厚生労働省から様々な方策で普及あるいは標準化の普及を進めていただくと。その中には、医療情報化支援基金の活用と診療報酬の活用があるということを説明いただきました。何か御質問はありませんか。
では私からです。診療報酬の話がありましたが、今年4月の診療報酬改定というのはかなり話が進んでいるので、恐らくこういう具体的な診療報酬への改定の反映というのは、タイミングとしては次のチャンスぐらいになるでしょうか。いかがでしょうか。
○金光補佐 保険局医療課です。今のお話は、恐らくHL7 FHIRに関係した診療報酬への盛込みが可能かどうかというような御指摘だったかと思います。11月26日の中医協総会において、HL7 FHIRに関係した資料もお出しさせていただいて、ただ、まだ取組としては先生がおっしゃられたように、出来上がっているものではないということの前提も踏まえた上で、どのようにしていくのかということについては、幾分お出しさせていただいたところです。診療報酬は医療機関に対して対価を支払うという性質を持っているものですので、出来上がっていないものについてお金を支払うことはなかなか困難な部分もあるかと思っておりますが、非常に重要な視点だと事務局としても受け止めていますので、引き続きできること、できないことは整理して中医協総会で御議論いただくことかと考えています。
○中島主査 お二方、手が挙がっていますが、先に挙がっていた松村先生、お願いいたします。
○松村構成員 松村です。診療報酬の最後、今見えている資料です。施設基準等の所に要件が書かれているのですが、ここが結構厳しい要件であるように思うのです。今後医療情報を流通させる際に、手順として、例えば、JAHISに、電子紹介状をやり取りするとか、あるいは処方とか検体検査結果を診療所との間で交換するとか、そういうテーマを示して、それを実現するためのシステムを作っていただいくことを前提に、機能要件を定め、作る側の人たちの意見も聞きながら、どういう要件のものだったら実現できそうだといった目途を付けて、合意がとれたら、実際に各電子カルテベンダーにパッケージを用意していただいて、それを使って運用したら診療報酬が取れるというような段取りで進めたほうが良いと思うのです。
というのは、条件だけあっても、例えばHPKIで電子署名を付けて病院側から電子紹介状を出せるかといったら、おそらく、ほぼないのではないかと思うのです。せっかくこういう算定要件を出していただいていますが、残念ながらこれを活用して広まっていくことにはなっていないのではないかと思います。ですので、今申し上げたような手順で、現実的なシステムをまず考えて、それを普及させるために診療報酬点数を付けるという手順で考えていただけたらいいのではないかと思います。
○中島主査 保険局の方、いかがでしょうか。
○金光補佐 保険局医療課です。松村先生のおっしゃっていることは、そのとおりだなと思って伺っておりました。我々はもちろん診療報酬の世界の中でどのような要件が適切か、どのような施設基準であればきちんと公平性や公正性が担保できるかと考えますが、一方で、これは医政局のお話かもしれませんけれども、どういったシステムが現実的に広く皆さんの合意を得て使っていただけるかということもあるかと思います。そこは両局でよく御相談をしながら、また現場の先生の意見も伺いながら使いやすい形、また、患者さんにとっても納得のできる負担になるような形での診療報酬を設計するということに努めてまいりたいと考えています。
○中島主査 宮田先生、どうぞ。
○宮田構成員 宮田です。発表ありがとうございました。先ほど中島先生がおっしゃったように、情報がデジタル化されている全体の割合がまだそれほど高くないというところはかなり大きな課題です。こういったものを全体として改善していく、底上げしていくという施策も重要である一方で、既に電子化されている所を軸にしながら、より踏み込んだ取組、今日この後も出てくるようなHL7 FHIRの話もあると思うのですが、それを広げていくこともすごく大事だと思うのです。1つは、例えば高度先進医療の中で、ある特定のゲノム医療、あるいは高度な一部の医療を提供しているときに、やはり患者さんの治療の実態をリアルタイムで把握する、あるいは有害事象があったかどうかというのをリアルタイムで把握することが大事だということになった場合には、こういった病院を分母にした場合には、恐らく電子カルテ率というのはもうかなり高いはずなのです。そうすると、そういった診療行為に対しては、デジタルで、リアルタイムで連動していくということを視野に入れた加算なのか義務付けなのか、こういった観点からも設計していくことは、アプローチとしてはすごく必要な部分はあるのかなと思います。これも保険局ですかね、いかがでしょうか。
○中島主査 保険局から何かコメントはありますか。
○金光補佐 宮田先生がおっしゃっていることは、我々も十分理解しているつもりです。それぞれの診療報酬点数のみならず、医療現場で使われるシチュエーションにおいて、医療情報が交換される医療機関の広がりのようなものは異なっているわけです。今日お示ししたのは、むしろ広い意味での情報共有とか情報提供というところで、少し幅広の観点での資料の提示をさせていただいておりますが、それこそ、それぞれの疾患領域とか患者さんの状態といったものに着目して提供する場合、また情報連携する場合の最適なというか、即した在り方というところに着目して議論を進めていくというのは大事な視点かと思っておりますので、厚労省の中でもよく議論してまいりたいと思っております。
○宮田構成員 よろしくお願いいたします。
○中島主査 ほかに何かありませんか。今日、少し時間がありますので十分に議論したいと思います。私からもう1つ、医療情報化支援基金に関して、これは医療施設に対して払われるということになっていますが、基金の性質が医療施設にしか払えないということになっているのでしょうか。例えばベンダーに払うとか、あるいは自治体に払うとか、何かそういう可能性は難しい基金なのでしょうか。
○田中室長 今のところ、医療機関に対してお金を支払うということを念頭に置いた基金になっております。
○中島主査 ということは、それに対して医療機関一つ一つが申請をせざるを得ないということですね。
○田中室長 然様です。
○中島主査 ほかに何かありませんか。松村先生、どうぞ。
○松村構成員 今の点に関してなのですが、医療機関に支払う基金だということなので、それはそれで、そういう設計をしたらいいと思うのですけれども、やはり医療情報が流通するために、ある部分に対して支払うとか、何か条件を付ける工夫をしたほうがいいと思います。目的が電子カルテを普及させることだということではありましたが、先に導入した医療機関はもらえなくて、後から導入した所はもらえるということになると、不公平感があってよろしくないと思います。ここでは、更新にかかる費用を負担すると書かれていますので、そういうことではないということは理解できます。電子カルテを入れたら一定の負担をするというと、ものすごく対象が広くて薄くにしか支払えないのではないかという気がします。だとすると、その基金をうまく活用して、医療情報の流通基盤がこれによって推進されるような方向性を示したほうが、発展性があると思います。
○中島主査 それは、例えば複数の医療機関で申請するとか、そういうことも含めての話でしょうか。
○松村構成員 いや、さすがに医療機関毎だと思うのですが、例えば、先ほど申し上げたFHIRで出せるとか、何か標準的な形でデータが出せるという条件を満たした場合に補助金を付けるとか、そういうことなのですけれども。
○中島主査 事務局、いかがでしょうか。
○田中室長 4ページの要件の案でお示ししているところには、データの入出力ができるということを記載していて、先生がおっしゃったように流通するということが大事ですので、出しっぱなしであるとかでは流通しないので、入出力ができるというような要件でそちらを担保しているところです。ただ、先生の御指摘のとおり、かなり対象が広くなってしまうということで、薄く広くになってしまうことについては、対象にフォーカスを当てるということは重要だと思っておりますので、最初にお示しした電子カルテの普及状況が十分ではないようなところについて、より重点的に対象として考えていく等の方策は必要だと思っております。
○中島主査 松村先生どうぞ。
○松村構成員 こういう機能を作るのはやはり電子カルテベンダーなので、電子カルテベンダーのほうでパッケージを用意していただいて、それを評価し、合格したパッケージを入れた場合に補助金の対象になるというような、そういう手順をとればかなり実効性が上がるように思います。
○田中室長 承知いたしました。検討させていただきます。
○中島主査 高倉先生、どうぞ。
○高倉構成員 高倉です。1つ前の3ページの所にちょっとコメントさせていただきたいのですが、カスタマイズを避けてほしいというのはごもっともな話である一方で、どうしてもそこの医療機関独自で、データを入れなければいけないということも起こり得るということを考えますと、標準パッケージ機能にカスタム領域、この領域はカスタムで使っていいというのをあらかじめ用意しておいて、そこについては認めましょうと。ただ、基本パッケージの機能そのものに手を付けるのはやめてくださいというように、少し自由度を与えておかないとまずいかなと思いますし、そういうことを考えて各パッケージメーカーが標準に合わせてくれればいいのではないかと思いました。以上です。
○中島主査 何か事務局からコメントはありますか。
○田中室長 御意見ありがとうございます。非常に重要な御意見だと思いますので、そのようなことも併せて検討させていただきます。
○中島主査 ほか、よろしいでしょうか。
それでは、次に行きたいと思います。（2）です。①は長島構成員がご欠席なので、②医療情報システム開発センター(MEDIS)での標準規格の維持管理について、今日は医療情報システム開発センター(MEDIS)の山本理事長にお越しいただいております。山本先生、よろしくお願いいたします。
○山本理事長 お話をさせていただく機会を与えてくださりありがとうございます。今日お話するのは、MEDISは長年コードマスターの管理をやってきたのですが、ようやく医療の情報化が進んでコードが必要になってきたときに、結構MEDISの標準規格のマスターが苦しい状態になってきているので、それも含めてお話をさせていただければと思います。
次お願いします。つまらない写真で恐縮なのですが、写真はつまらなくて絵は立派なのですけれども、これはピーター・ブリューゲルの「バベルの塔」の絵でありまして、標準化を話すときに、必ず私が引用している絵です。旧約聖書にある逸話の中で、天に届く塔を建てようと人類が思って、怒った神がそれぞれの民族の言葉を別にした。つまり標準的な通信手段をなくしてしまったのです。そうすることによってこの塔がこの絵にあるような非常にいびつな塔になって、神の国に届くどころではなくて、途中でところどころ崩れ出すというような、非常に悲惨な結果になっているという絵です。これはウィーンのKunsthistorsches Nuseumにある絵で、そこは撮影可ですので私が写真を撮ってきたのですが、こういったことを常に頭に置いて標準化を考えていかなければいけないということで、皆さん既に御承知のことですが出させていただきました。
3ページ、データの標準化はいったいなぜ要るのかという話を、もう皆さんよく御承知のとおりですが、一応確認の意味でさせていただきたいと思います。患者情報を伝える。一人で見るときには標準化も何もないわけですね。それを複数のステークホルダーがその情報を扱うときに、やはり伝送というのがあって、当然ながら観測とか測定をやられて、データにして、そのデータが伝わって、それをまた再構成して患者情報にするというプロセスが働くわけです。
4ページ、一般に医療従事者、つまり専門家というのは非常に解釈能力が高くて、例えば医師であればいろいろなデータといろいろな解釈者がやったような、例えば手書きで書いた紹介状を見ても何とか患者さんの情報というのは再構成できるものなのですが、一方で最近は多施設間連携、あるいは多職種連携、あるいはPHRに代表されるような、長期間蓄積される情報がある。経験値による解釈というのがあまり期待できなくなってきています。どうしても機械的に解析をする必要が生じてくるということで、機械的な解析をするところに関して、非常に大きな問題が生じてきているということになります。
5ページ、PortabilityとかInteroperabilityとかという言葉があるのですが、皆さんがご存知のようにいろいろなレイヤーがございます。一番上流のレイヤーは目的を共有しなくてはいけない。バベルの塔であれば神の国に届く塔を作るであるとか、例えば糖尿病であればACRの糖尿病をコントロールするという目的があって、手段がございます。これは階層構造を基本に、下から積み上げ式で作る。バベルの塔の場合はそうですね。手段の場合は、例えば糖尿病ガイドライン、連携パスを使うとか、情報伝達手段、これはバベルの塔のことであれば連絡担当を決めて定期的に会合を持つみたいなことになります。現在では例えばHL7ver.3CDA準拠の文書に処方、検査結果はHL7ver.2.6、あるいはFHIR変換したものを使うというのが手段になります。それから、言葉の問題があります。例えばバベルの塔であればエスペラント語を使うとか、現代の医療であれば、医薬品コードはHOT9を使いましょう、病名は標準病名マスターを使う、検査はJLAC11を使いましょうというようなことを決めていかなくてはいけない。
それから概念もあります。石材とは何かとか、隙間をなくすとはどうすることか、医療の場合では肥満とは､理想体重とはと、こういった概念をそろえておかなくてはいけない。その中身のコンテンツ、石材といっても取れる国によって性質が違う。血圧を測っても家庭用血圧計と健診機関、医療機関の精度管理の問題があります。
6ページ、その中で今までMEDISが主に担当してきたのは、この赤で囲った所の用語とコードマスターの問題です。
7ページ、これが現在、我々の所で管理をしているコードマスターで、これだけあります。
8ページ、一覧表にまとめたものがこの表です。全てではないのですが、これ以外に例えば医療機器データベースなどがあるのですが、コードマスターとして使われているものがこれだけあります。上から標準病名マスター、歯科病名マスター、手術・処置、歯科手術、看護実践用語、これは看護観察と看護診断がありますが、臨床検査マスター、医薬品はHOTコードマスター、症状・所見、画像検査といっても画像検査の方法と部位に関する用語のマスターです。足りない部分があって、医療情報学会である程度まとめていただいていますが、用法・用量マスター、あるいはまだ作成中ではありますが、アレルギーのマスターというのがきちっと整備された形で残っているというわけではないということです。
それぞれのマスターには一応目的があるのです。この中の病名マスターから歯科手術マスターの4つに関しては、診療報酬請求に使われるというのがかなり大きな目的になっています。それだけではなくて、例えば地域医療連携、医療介護連携などで、標準的な情報を共有するという意味でも、このマスターは使われる。手術・処置マスターに関していうと、診療報酬請求上にはKコード等も、それ以外にも幾つかあるのですが、今外保連がSTEM7という手術マスターを作っていて、これが非常に現場に即した良いものになってきているので、せっかく外保連で作っていただいているので、将来は多分これに移行したほうがいいのかなと。Kコードの関連もかなり整備されてきていますので、いろいろな部分があると思います。歯科病名、標準病名、歯科手術マスターは今のところMEDISで管理しているもの以外にはないということになっています。
それぞれ診療報酬請求の非常に重要なパートを占めますので、最終受益者の中には、保険医療制度利用者、要するに医療保険制度を使っている利用者、これは医療機関もありますし、支払い側もあります。そういったものが最終受益者になって、こういったものは非常に国民皆保険制度の下では、公益性の強いマスターになります。
看護実践用語標準マスターは、診療報酬請求に無関係ではないですが、全てが使われているわけではないのですが、医療行為のアウトカム評価をする上で、非常に重要なマスターで、皆様御承知のように、例えばイギリス等ではNHSによる税金による支払いなのですけれども、かつては人頭支払い、つまり登録患者数による支払いが中心だったのですが、最近はアウトカムファクターが非常に大きなパートを占めています。つまり、やはり効果がないと認めていけないということに移行しつつあるのだろうと思います。そういう意味では我が国の保険医療制度でも、そのような評価が非常に重要になってくることは当然のことだろうと思いますので、それに使っていくという意味では、これも非常に重要で、しかも公益性が強い。将来は保険医療制度利用者に対して非常に重要なマスターになると思います。
10ページ、臨床検査マスターと医薬品HOTコードマスターは意味が違うマスターで、臨床検査マスターというのは、臨床検査の項目名だけではなくて、多軸のマスターで、臨床検査を行う試薬でありますとか、測定方法でありますとか、そういったものがこのコードを見るだけである程度分かるというマスターになっています。何が大事かといいますと、臨床検査は日々進歩していきますので、例えばPHRで長い間のデータがあるときに、ある時期から検査方法が変わってしまうということがしばしばあるのです。そのときに前の検査結果と新しい検査結果が同じ意味ではなくなってしまう。つまり一定の変換をしないと、継続したデータとして扱えないということが比較的多く起こってくるわけです。そういう意味では電子的に非常に多くの施設でデータを交換するとか、あるいは非常に長期間のデータを見るという意味では、必須のマスターになってきますが、単純に1つの時間帯の中だけで見ると、それほど有用性がないのです。
したがって1つの医療機関だけで医療が完結していた時代には、こういうことはほとんど省みられなかったわけですが、最近のように生活習慣病や悪性疾患のように、非常に経過の長い病気が主体になってきたり、あるいはPHRによって生涯にわたって情報を管理するという時代になってくると、これがないと非常に困るマスターになってきます。医薬品HOTコードマスターの医薬品というのは、1つのものがあって、それに対してコードが振られて、この医薬品のコードというのは、10種類ぐらい既に存在しているのです。それぞれ目的があってコードが振られていて、その目的で使うには非常に便利なのですが、この10種類のコードが1つの文言のどれに属しているかというのを結びつけるコードがないので、目的ごとに違うマスターを整備しなくてはいけないということがあったので、HOTコードマスターというのは、10種類近くある医薬品マスターを、串刺しというか、結びつけて管理するためのコードマスターで、一方でそれに加えてそれぞれの既存のマスターの欠点をできるだけ吸収するような形で整備されたマスターです。このマスターがないと駄目というわけではないのですが、複数のコードが振られた医薬品の情報が、例えば処方箋に引かれているコードでありますとか、あるいは医薬品の在庫管理に使うコードでありますとか、そういったものを1つの医薬品のものであるということを機械的に管理するために、インデックスマスターみたいなものですね、そういったもので必要になってくるHOTコードマスターです。
これはどちらかというと医療の情報を医療機関同士で、あるいは医療機関から医療機関、あるいは医療機関から薬局、あるいはそれに加えて薬局の在庫管理であるとか、そういったことを可能とするマスターがHOTコードマスターです。臨床検査マスターの場合は、検査方法が異なっているような施設間で、検査値を比較する。あるいは途中で検査方法が変わってしまったような検査値と比較するという、時間軸、平面でも非常に多岐にわたるような場合に、非常に重要なマスターになります。これはどちらかというと患者自身にメリットがある、あるいはそういった患者さんをある時点、ある時点で管理をする、ケアをする医療機関にメリットがある。それから時間軸に沿って分析をしなくてはいけないような行政・研究者にメリットがあるというマスターで、保険請求とはあまり関係ないマスターになります。
その下の症状・所見マスターは、余り使われていないです。画像検査マスターは、放射線技術学会がJJ1017委員会を作って管理されているマスターですが、余り変更のないマスターで、それほどメンテナンスにものすごく労力を使っているわけでもなくて、これは放射線技術学会の委員会にお任せをして、我々はポイントを押さえているだけというマスターになります。
最後に、このマスターの維持・管理に必要な、現状かかっているお金を、直接関与している人件費を含めて書いております。これだけ合わせると、ほぼ8,000万円近いお金が毎年かかっているのです。これ以外に事務経費がかかりますので、もう少しかかっているのですが、MEDISは10年前に一般財団法人になって、そのときにこの事業全体は厚生労働省の委託事業の形でお受けしていて、そのときの委託経費というのはほぼこの額だったのですが、当然なのですが、行政の中でのこういった委託事業というのは、毎年毎年査定されて、それなりに減っていくという仕組みでやっているわけで、現状は40％ぐらいに減っている。ということは、毎年この60％の費用をMEDISが手弁当で管理をしているというので、我々もできる限り頑張ってきたのですが、なかなか辛くなってきて、この辺りで、これは非常にそれぞれ意味のある、特に上の7つのマスターは非常に意味が大きいマスターですので、これをサステナブルな形で管理をしていかなければならないということで、これをどのようなサステナビリティを持った管理の方法があるのかというのを、厚生労働省医政局の皆様方と相談をしている最中であります。
11ページ、標準化は非常に大事なのですが、あまり過度な標準化というのは、実はイノベーションを制約する可能性がありますし、もっと大事なことは先ほども申しましたが、継続的な保守が必要で、保守されないという標準が弊害になってしまうのです。そういう意味では間違いなくきちっと保守をしていかなくてはならない。それぞれのマスターに関して結構保守にかかる手間は大きくて、病名にしてもこれが病名として認められるか認められないかによって随分変わってくるような、社会的問題などもあって、担当している職員の所には結構しょっちゅういろいろな所から電話がかかってきて、それに対応しなくてはいけないということもあって、なかなか手間のかかる問題です。したがって必要な標準を整備しなくてはいけないのですが、本当に必要なものをきちっと評価をして、必要なものに関してはきちっと継続的に評価をする。標準化したらいいのではないかというような軽い気持ちでやると、後でどうしようもなくなるということが、これまでも幾つかあったように思いますので、そういうことがないように気をつけてやっていかないといけないと思っております。
私の話は以上です。どうもありがとうございました。
○中島主査 山本先生、ありがとうございました。大変分かりやすく、課題もしっかり示していただきました。何か御質問、コメントなどはありませんか。宮田先生、どうぞ。
○宮田構成員 山本先生、ありがとうございました。本当に標準化だったり、あるいは価値のある項目、Portabilityに向けてどういう論点が必要かという課題を本当に明瞭に示していただきましたし、手弁当とおっしゃいましたが、本当に素晴らしい取組に敬意を感じています。
おっしゃっていただいたとおり、Portabilityライトアクセスという概念はすごく大事なのですが、全ての情報に対して求めてしまうと、サステナブルではないのです。これは現場にも過剰な負担になってしまうので、どこをミニマムとしていくのか、あるいは、特に最初の段階に関しては、段階的にですよね、山本先生も関われたミニマムデータセットというのもあると思うのですが、検査値とか、既に標準化というものが、かなりされている部分から段階的にやっていくとか、工程だったり、あるいは管理の仕方も含めたことがすごく大事なのかと思いますが、山本先生としては、例えばPortabilityを医療で進めていったときに、どういう項目から始めていくのが推奨されるかみたいな部分を質問させていただければと思うのです。
○山本理事長 ありがとうございます。スライドを１つ戻していただけますか。この中で上の５つ、これは診療報酬請求に関係しますので、ここは少なくとも診療報酬請求に関わる制度といいますか、粒度では、網羅的にやっていく必要があって、ここはやむを得ないと思うのです。現状、そうできていますし、それなりのメンテナンス体制ができています。
問題は、その下の次の2つなのです。これは臨床検査マスターに関して言うと、JLAC10とかJLAC11という名前が付いていて、これは臨床検査医学会と医療情報学会とMEDISが三者でメンテナンスをしている。主には臨床検査医学会が中心になってやっているのですが、検査を扱う人にとっては、このコードは非常に大事なのですが、流通という面で言うと、今、臨床検査マスターがコード表に載っている項目、項目ではないのですが、そのコードの種類の数は約1万あるのです。実際、複数の医療機関で使われている検査項目はどれくらいあるか。つまり、たった1つの医療機関でしかやられていないという検査は別にすると、それほど多くなくて、1,000以下なのです。10分の1以下が実際に流通される検査コードになります。例えば、生活習慣病などの場合は、当然ながら複数の医療機関で管理することがあって、これに関して言うと、きちっとコードを振ったほうがいい。それ以外に本当に1つの大学病院でしかやっていない検査は、実はこれはコードが何であろうと、実は関係なくて、ほとんど結果を人が見て解釈する以外に方法がないわけです。これは余り勢力的にやっても意味がない。そういう意味で、ここに臨床検査マスターの項目の最後に、頻用検査というのがあって、ここは実際に複数の医療機関で行われる可能性が非常に高いマスターは、別に作っているのです。これはやったほうがいいと思う。
医薬品に関しては、これは物がありますので、その物に対するコードです。要するに、これは新しい医薬品が開発されたら、その開発された医薬品がまず薬理学的にどういう薬であるかということと、剤型がどうであるかということと、患者さんにわたすときの包装単位、1シートなのか、あるいはばらの錠剤なのかというぐらいのところまでは、きちっとコーディングする必要があります。例えば、YJコードだと、どこまでは表現できるというのがあるので、それなりに今使われているコードを使っていただいていいのですが、それを串刺しにするコードとして、このHOTを決めていくことは大事だろうと思っています。
ですから、今の宮田先生の御質問にお答えするのは、上の5つに関しては、取りあえずは制度を維持する粒度、この維持はしなくてはいけない。臨床検査マスターに関しては、コード自体は臨床検査医学会が振っていただけるのですが、これを普及させるという意味では、多数の医療機関で行われている検査に関しては、普及をしていく必要があるだろうと思います。医薬品に関しては、結び付けのマスターですので、そうすること自体がそれほど大変ではありませんので、これはやっていかなくてはいけないだろうと思っています、ということです。
これ以外のマスターに関しては、相当慎重に考えていかないと、決めたことによって、かえって負荷が高くなることになって、逆効果になってしまうこともあり得るのではないかと思っています。以上です。
○中島主査 ありがとうございます。ほかに何かありませんか。松村先生、どうぞ。
○松村構成員 山本先生、こんにちは。大変ご苦労されながら、非常に重要な成果物を出していただいて、ありがとうございます。私は、実は中島先生と一緒に、臨中ネットといって、臨床研究中核病院で研究事業をするためのデータの標準化をする活動に参加していまして、検体検査結果コードをどう臨床研究中核病院間で合わせていくかといった具体的な作業を担当させていただいて、やればやるほど大変だということを実感しているところです。
コードを定めるのももちろん大事ですが、どのように各医療機関にそのコードを振らせるかも重要になってきます。現実には、今は各医療機関はローカルコードで運用していますので、ローカルコードとJLACコードを対応させる対応テーブルを作る作業が、どうしても必要になります。それをどういう手順で作ると、正しく作れるかというところが重要となります。
そういったところにMEDISとしての指導を頂くのも期待したいと思います。臨床検査医学会はコードを振ることに専念されていて、それをどう普及させるかは見えてないところがあります。やはり、どこかセンターとなる所を日本で定めて、しっかりとコントロールすることがないと、現実問題、普及していかないと思うのです。臨床研究をする上でも、標準コードは非常に重要な意味を持ち、今まで各病院で運営していたときとは全然違う話になってきます。ですので、その点で、ご活躍いただきたいと思っているところです。
もう1点、JLAC11ができますよね。JLAC10を我々はいろいろ調べたのですが、本当に御指摘のとおり、いろいろ欠点があります。同じ意味の概念だけども、振り方が何通りもあって、どれが正しいかは客観的に示せないという問題があり、そのため、同じ概念なのに、病院ごとに違うコードを振ってしまっているという結果となっています。それをきちんと直したのがJLAC11で、JLAC11に早くシフトしたほうが良いと思っています。そういう舵取りもMEDISのほうでしていただければ、有り難いと思っています。
○山本理事長 ありがとうございます。今、臨床検査マスターはJLAC11併記になっていますので、JLAC11として使っていただくことも可能になります。JLAC11とJLAC10と多少違いますが、そうなっています。
コーディングの支援ですが、実は我々の所でも、これも九大の康先生などと一緒になって一応進めていて、一番簡単な方法は試薬からなのです。この検査に使っている試薬があります。その試薬に対して、1個には特定されない試薬もあるのですが、その場合は、例えば3個とか4個の全17ケタのJLAC10コードやJLAC11に振り直すと、そのコードに分かれることを指定することは可能です。ですから、試薬が分かると、後はほんの1つか2つ質問をすれば、コードが確定するという仕組みになっています。その仕組みを我々のほうで開発をして、必要があれば、それぞれの検査センターあるいは検査室に提供していますし、それでも難しいということであれば、試薬を教えていただいたら、こちらのほうでコードの可能性のある表を作って、なおかつ、それを確定するために少しインタビューさせていただいて、そのコードの変換表を作ってお返しするというサービスもMEDISで一応やっているのです。
ただし、この場合は、あくまでも頻用検査が中心で、例えば東大病院だけでやっている検査というのは、そこは勘弁していただいているのです。800項目の頻用検査に関しては、変換テーブルを作って、一応有償にはなりますが、それほど高いお金ではなくて作ることもやっています。だから、試薬からJLAC10、JLAC11コードを振るツールに関しては、提供しておりますので、もし臨中ネット等でそういったのを使ってみたいとかがあれば、御相談いただければ、協力をさせていただきたいと思います。
○松村構成員 ありがとうございます。実は臨中ネットで300ぐらい項目を定めて、JLAC11コードにしてしまおうとしたのです。そしたらないと、まだほとんど確定されてないというのがありました。それがまだ確定しないのだというお返事だったのです。その辺を急いでほしいなということ。決してそれほどレアな検査ではなくて、一応臨床研究でよく使う項目だけを選んで、やっぱりそういう状況であって、ちょっとまだ広がりという意味で十分でないなと言う気が。
もう1つは、先ほどの試薬の件ですが、実は試薬のところのコードをしっかり付けるということも、理想的な意味では大事ですが、差し迫って必要なのが、いわゆる臨床検査の項目名の粒度に合致するコードを、まずは決めたいというところがあるのです。例えば、今、臨時的に阪大が各臨中ネットに参加する病院に対して、このコードに対してローカルコードを教えてくださいという問合せをしているのです。そのときに、JLACの細かいコードを出すと、途端に話がややこしくなってしまうので、例えば血液中のASTとか、血液中のALPとか、そういう言葉に合致するような粒度のコードをまず割り当てて、それを管理コード的に使って、それの属性コードとしてフルのJLACコードを付けるみたいな扱いをしたほうが楽になると、特に私は思っています。ですので、そういう柔軟な扱い方をできるように体制を準備いただけると有り難いと思っています。
○山本理事長 ありがとうございました。JLAC10の最も大きな欠点はそこなのです。あれは項目名という概念がないのです。したがって、項目名を分類コードにすることが非常に難しい。それの対応もJLAC11の主な目的の1つになっていますので、JLAC11に移行ができれば、そこが少しはましになってくるのだろうと思っています。完全ではないですが、少しはましになってくるのだろうと思います。
○中島主査 ありがとうございました。ほかに何かございませんか。それでは、山本先生、今日は本当にありがとうございました。またよろしくお願いします。
(山本理事長退席)
○中島主査 それでは次に行きたいと思います。
次は、前回のこのワーキンググループで、HL7 FHIRが、大分進歩してきたので、その現状の説明を次ぐらい、本会議ぐらいにしていただきたいと申しました。本来、HL7 FHIRは、私が代表理事をしております日本医療情報学会の活動の中にNeXEHRSという活動がありまして、東京大学の大江教授が代表をされているので、大江先生に説明をしていただくのが一番よかったのですが、今日はどうしても都合が悪いということで私から説明をいたします。まず、参考資料4に、HL7 FHIRについては詳しく概略が書いてありますので、そちらを御参考いただければと思います。HL7 FHIRが少し進んできたというところから話をします。
次、2ページ、2020年度に大江和彦先生が代表を務めておられました厚生労働科研で、このFHIRの記述書を4つ作られました。処方情報、それから健康診断、これは特定健診の健康診断結果報告書、それから退院サマリー、診療情報提供書、この4つのFHIR記述仕様を去年の3月までに作られて、現在は、これが全て厚労省標準になるべく、今、HELICS協議会という所で審査中になっております。もう既に、2つは日本医療情報学会の標準で、2つは日本HL7協会の標準、このように急ピッチでこのFHIR化が進められている現状です。
3ページ、FHIRというのは、こういうリソース、Bundleリソースと言いますが、一つ一つの情報の固まり、例えば、ここでは特定健診結果報告書、こういうBundleリソースという形で、それぞれがその構造を決める、このように細かく決めている形で作られていきます。また、こういうリソースを自由に組み合わせて実装することも可能になっています。これは特定健診ですが、例えば処方情報だとか、退院サマリーだとか、あるいは診療情報提供書でそれぞれ作られてきたことになります。また、今年の厚労科研でも幾つか作られていくことになります。
4ページ、厚労科研のFHIR仕様の成果物のホームページがあります。昨年度の成果である4つの仕様書は既に公開されています。
5ページ、そもそもこのHL7 FHIRというのは、国際標準規格で一番下にありますが、HL7 Internationalという団体がありまして、ここが一番基本となる仕様を決めています。これは世界ユニバーサルな規格ですが、その上に、それぞれの国に実装するための一番基本的な、日本であればJP-Core、アメリカであればUS-Core、台湾であればTW-Core、そういうものが必要になります。例えば名前をどのように実装するかは全て、基本的なことばかりですが、決められています。これがないと実際には、その上にあるFHIR仕様というのは実際には実装してもなかなか定まらないことになります。実は、これが去年の暮れにようやくほぼ出来たということが今の状態になります。
これの上に、上から2番目ですが、例えば診療情報交換における仕様、あるいは、右側は臨床研究における仕様、これで、目的が違えばやはり仕様が違いますので、その目的に応じた仕様のコンパクトが行われて、その上に、先ほどの4つ、これは診療情報の交換ですので、こういうユースケースごとの仕様が決まっている。これを医療で使われる様々なユースケースごとに作っていくことが必要になってきますが、これが作られると、比較的、これまでのHL7の規格にも実装がしやすい。あるいは、例えば患者さんの持っているスマートフォンなどのPHR、こういうものに実装しやすい規格ということになります。
6ページ、これが、昨年末に、これは一応まだVer.1 Draftと書いてありますが、ドラフトとして公開しています。これがJP Coreという、日本におけるFHIR仕様の基本になる仕様になります。
7ページ、このワーキンググループでは、厚生労働省のデータヘルスの集中改革プランというものが最初に紹介されましたが、3つのACTIONが、今、2年間で行われています。ACTION1からACTION3まであります。特にACTION3、自身の保険医療情報を活用できる仕組みの拡大、この中にPHRもありますが、特にこれにFHIRが介入します。HELICS協議会のホームページに4つの、今、審議中の規格が書いてありますが、上に5つありますが、一番下以外は、HL7 FHIRの仕様書になります。これが現在、審議中でして、できれば今年度中に決まってほしいと我々も考えております。
8ページ、今のACTION3を、少し分かりやすいように図に落としてみました。右上にACTION1にも関連するオンライン資格確認、あるいはそこから連携するマイナポータルのことも書いておりますが、主にこの青い矢印で書いてありますのがHL7 FHIRの仕様になります。右側がPHRです。個人が持つ個人の情報端末、スマートフォンです。あるいは、それに接続されるIOT機器。左の半分が電子カルテネットワークと言いますか、病院間のネットワーク、あるいは、医薬連携、病院と薬局の連携がこのネットワークになりますが、これらをFHIR基盤、Open FHIRと書いていますが、この基盤で結ぶ。そして、PHRとの間も、EHR-PHRデータ交換の基盤で結ぶものが、今、考えられています。
これらは、1次利用をまず想定して、そして、さらには2次利用にも使えることになりますが、1次利用でこのようにデータが流通しますと、左側にあるように、次世代医療基盤法、こういうデータ2次利用の基盤でデータを集めても、今はまだ標準化が進んでいない現状では、なかなかローカルコードでデータが集まってきてしまったりすることによって、データの2次利用を非常に阻害してしまうことになりますが、このような基盤、1次利用の基盤が進みますと、つまり標準化が進みますと、このデータの2次利用も進むことになります。
9ページ、具体的に、今の図と、それから、NeXEHRSという活動が考えているFHIR基盤、これの関連を理解していただこうと思いまして、この図を持ってきました。これはNeXEHRSが考えています参照モデルです。つまり、実際に社会的にまだ実装する前の参考にするようなモデルですが、これを使って説明します。左側にA病院とあります。右側に、病院の外にFHIRの連携基盤があります。A病院の電子カルテ、これから青い矢印が右側に伸びていますが、FHIR Gatewayというのを通って、FHIR連携基盤のA病院という所に、これがFHIRサーバーになりますが、この電子カルテの中身が格納されます。同時に、病院側にも同じもの、全く同じものがA病院の青いFHIRサーバーに格納されます。右側のFHIR連携基盤のA病院のデータは、例えば、24時間たつと自動的に患者ごとに患者に連なる形で管理されている個人単位管理FHIRサーバーにやはりコピーされます。こうすることによって、例えば1人の患者さんがA病院とB病院に行っても、ピンクの患者サーバーには1つのIDに連なるデータとして管理されます。これを、下にありますように、1人の患者さんがPHRに、あるいはスマホのアプリに落として使うことができるようになります。
このFHIR連携基盤というのは全国に1つというわけではなくて、例えば、10ページのスライドになりますが、ほかのFHIR基盤ともFHIR Gatewayを介してつなぐことができます。FHIRというのは、アクセス権限管理などを非常に柔軟に、かつ精緻に行うことができることが特徴でして、このようなFHIR Gatewayを作ることによって、例えば、地域主体のFHIR連携基盤があったり、あるいは、電子カルテベンダー主体のFHIR連携基盤があったり、様々にこういう連携基盤が作られても、FHIR Gatewayを介して、あたかも同じ連携基盤上にあるように連携をすることができることになります。一番右側にありますが、この図は、先ほどのPLATと呼ばれる参照モデルを実際に社会実装したときのイメージ図ですが、個人のデータの管理基盤は必ずしも同じ連携基盤の中になくても、このPHR基盤事業などで、これをPHRの基盤として持つことも可能になります。これがやはりFHIR Gatewayを介して、患者さんが同意をすればそれぞれの病院からPHRの中を見に行くことも可能となります。
さらには、現在、200以上の地域医療連携ネットワークが、この地域医療連携ネットワークは、FHIR基盤ができたらどうなるのかということをよく聞かれるわけですが、これはやはり、ワーキンググループの最初にありましたように、これだけの熱心な方々もおられますし、そういう基盤がありますので、FHIR基盤と連携ができれば、このネットワーク上で、幾分の制限はありますが、連携していくことは可能だろうということが言えます。さらに、更新などのタイミングで、今、Human BridgeとかID-LINKと書いてありますが、こういうFHIR Gatewayを介する、あるいは、またさらに上のPLATの連携基盤にありますような、FHIRサーバーをどんどん増やしていったりすることによって、だんだんFHIR化されていくと言いますか、FHIR基盤化されていくことによって、これらが有機的に連携されていくとイメージできると考えています。まだ、これがどこにあるかと言われると、まだ存在しないわけですが、この参照モデル、現在、NeXEHRSで構築中ということで、イメージとして今日、報告、紹介しました。
これは最後のスライド、10ページです。あまり分かりやすい説明ではなかったかもしれないのですが、何か御質問とかコメントありませんでしょうか。松村先生、どうぞ。
○松村構成員 詳細な説明ありがとうございました。非常に具体的なイメージが示されていて分かりやすかったと思います。最初に、厚労省で、標準的電子カルテで、FHIRベースのものを作った場合に、これを評価した上で、補助を出すという政策を考えてみたらいかがかというお話がありました。この絵にマッピングすると、各病院ではFHIR Gateway/Meta applicationが必要なわけです。つまり、レガシーなデータベースから、データをFHIRの形にして、連携基盤のほうに投げるという機能を、各電子カルテが持たないといけないことになるので、これを各ベンダーに作っていただいて、この装備を導入した場合には補助しますということにすると、このモデルが一気に展開できると思うのです。
FHIRというのはリソースベースでの考え方なので、今までの言い方から、FHIR風の表現にして、どのリソースを対象にするかということをきっちり決めて、このリソースに対してFHIR化できたら動かすといった、具体的な方向性を示したほうが良いと思います。では、どのリソースを対象にするかといったときに、大江先生が既に幾つか規格を作られていますが、やはり日本できちんと誰かがしっかり考えて、標準規格化する手順が踏まれたものを対象にしていくべきだと思います。
その点で、リソースとして増やしていただきたいというものがあります。電子カルテ全般のことを考えていくと、もう少し抽象度の高いレベルでのリソースも扱ったほうがいいと思います。1つは、テンプレートで入力したデータなどに該当するQuestionarire Responseリソースとして定義されているものです。これについて、議論することから始めていただきたいと思います。同じような観点で、文書についても、FHIR化して外に出せるような形を定義したほうが良いと思います。と言いますのは、リソースは、結構切りがないぐらいたくさんあって、これを文書という形でまとめると、応用が利きやすいと思うからです。電子カルテ上で、現状ではコード化されていない文書が、例えば、何かのレポートといったものがたくさんあるわけです。EHRとして利用しようとした際、例えば、放射線レポートが見えないとしたら片手落ちになります。そういったものをできるだけ早く吸収するためには、抽象度の高いリソースを定義して、これらを早くEHRに移せるように準備していったほうが良いと思います。
○中島主査 ありがとうございます。前半と後半とがあったと思うのですが、どちらも私は賛成です。特に最初のほうは、FHIR Gateway/Meta applicationとありましたが、これがあって、かつ、例えば電子カルテベンダーがこれを電子カルテの項目と紐づけていけば、この中に参入できる、連携基盤に連携できるということになりますので、これがないと、先ほどの、医療情報化支援基金ですか、この条件にしていくのはやはり必要ではないかなと思います。
後半は、こういう基盤ができたら、電子カルテの中身がどんどん自由に連携できるわけではないのです。これは非常に、FHIRによって実装はしやすくなったのですが、一つ一つの項目を本当にこつこつと紐づけて、先ほどのユースケース化、リソース化していかないといけないのです。これが、実はあまり進んでいないというのも私は賛成で、そのとおりだと思います。今あるFHIRというのはシステムの標準化ですが、臨床的な標準化は、先ほどのテンプレートという話がありましたが、テンプレートに出すような、この疾患で、あるいはこのユースケースでこういう情報が、フリーテキストでなくて構造で欲しいとか、あるいはこういう文書が欲しいとかいうことが、あまり臨床側で進んでいないので、是非これを大急ぎで同時併行で作っていく必要があると思います。それがあって初めてFHIR基盤がいきていくということだろうと思っています。ありがとうございます。事務局は何かございませんか。
○田中室長 特に大丈夫です。ありがとうございます。
○中島主査 ほかに何かございませんか。それでは次に行きたいと思います。
次は、④の標準電子カルテの検討にあたって、技術やセキュリティ対策の選択と集中について、これを情報処理推進機構IPAのCIO補佐官の葛西研究委員に今日は来ていただいております。それでは、葛西先生、よろしくお願いします。
○葛西参与 こんにちは、葛西です。何人かの先生はご無沙汰しておりまして、相変わらず実は厚生労働省のデータヘルス分野の技術参与も拝命してやっておりますので、引き続き御指導よろしくお願いします。
まず最初のページですが、私の場合はデータヘルス改革というのは幅が広くて、医療から、介護から、がんゲノム等々まで幅広く助言活動をしております。その中で、当然各国はどういう動きをしているのかかなり前からよく調べてきております。何人かの先生には相変わらず同じことを言っているなと叱られそうですが、私はテクノロジーの専門なので、テクノロジーの視点から見ますと、いわば人間が作ったものですから、人間の生態系と一緒で、テクノロジーも同じように生態系をたどるという、たとえどういうふうに動こうが、テクノロジーの成長過程はどこの国がやっても大体似たり寄ったりです。途中で何か失敗をしたり、今、成功している所もありますし、全くもうやめてしまうような所もあるのです。
私が着任してもう6年目になりますが、着任したときよりも前から、もう20数年来、多分この分野は日本でもされてきていると思います。当初進んでいたのは、実はアメリカとイギリスで、この2つはかなり進んでおりました。今、NHSというのはイギリスですが、イギリスの場合スパインという認証基盤です。シンガポールもシングパスという認証基盤を構築しています。これはもうかなり前から作っております。その後、スパインをベースに医療情報を交換しようという話が出てきて、標準電子カルテの指定をNHSはかなり早期にします。いろいろな検討会でも先生方がNHSの例を幾つかお出ししますが、クラウドを使った電子カルテ4つぐらいを指定して、その中で今、大体2つぐらいに集約されてきたかという感じがします。
実はシンガポールもHクラウドという整備を2017年ぐらいから検討し始めて、2025年までに完全に作り上げるという計画で進んでいます。シンガポールは公的病院が10しかなくて、そのうち9が全部Hクラウドというヘルス・ケア・クラウドを利用しています。それによって、監査法人がシンガポールのアセスメントをしたのですが、大体数百万ドルぐらいのコストの差があるという、かなり下がったということをはっきり明言して、これは第三者評価でしているのです。各医療機関も費用が半分以上の55％ぐらいに圧縮できたということで、非常に好事例になっております。
オランダは一時失敗をするのですが、その後、認証基盤を再整理して、これはオプトイン、オプトアウトを含めて再整理をして、LSPというFHIRの基になるような仕組み、データを交換するプラットホームを作って、今、データ交換がうまくいっている感じになります。
これはどこの国も、その後NHSもオランダもシンガポールも何をしたかと言いますと、ネットワークがばらばらにあるのでまず統廃合しようという話になるわけです。これもかなり金額をかけると。そして、いよいよクラウドという技術が出てきたのが2010年ぐらいになって、我々の業界ではクラウドリスト言いますが、クラウドに1回現状あるシステムを全部乗せてしまって、それで集約しようと。セキュリティも全部集約しようという動きが始まったのが、大体2015年ぐらいからというところです。
その後、一部データは、日本はここから少し成長過程が違うのですが、FHIRによる一部データ交換というのは、中核となる標準電子カルテを作って、その中から例えば少し障害があるとか、特殊な治療を行っているという方の情報だけを取り出して交換するとか、診療情報提供を取り出して交換するという、全部のデータの中から一部データを取り出して交換するという仕方でFHIRは成長してきている技術です。クラウドを真ん中に置いて、いろいろなオンプレミスであったり、スマートフォンであったり、パソコンであったり、いろいろなものと交換するための技術としてFHIRは成長してきたというところです。
同時に、標準化で困難な状態になりますので、各国はどうやってこれを法律的にFHIRコアを作るかとか、FHIRのマッパーを作るかというところに今、正にチャレンジをしているというのは、各国と日本は変わらない。日本はこの成長過程で少し違うのは、クラウドによる集約とクラウドを中核とした固有情報の交換、固有情報というのは、先ほど言った診療情報提供書や、特殊な治療をしている方の情報だけとか、そういったものを交換するという行為をほぼ同時に今検討している。いわば、ヘルスケアのデジタライゼーションでは、この3年ぐらいが少しぽっかりと各国に対して比較すると少し成長過程が違ってきている。これは良い悪いではなくて、成長過程が違うというところです。
ネットワークのオープン化をして、どこの国も閉域網をやめて、キャリアVPN、回線連絡を使っているVPNからいよいよソフトウェア、オープンVPNに変えていこうという動きが進んでいる状況です。
次のページ、その中で、私は大分この分野をやっておりまして、アカデミアではやらないですが、国のほうではこの議論は多々あって、やはり同じようにFHIRの話をしてきています。ただ、私はエンジニアですのでエンジニアの視点でのお話をさせていただきたいと思います。
どの分野でやっているかと言いますと、実はゲノム医療をする際の診療情報を取得する仕組みを、今APIで交換することを進めております。これは研究事業というよりは、国の事業として進めておりまして、そこに助言活動をしております。
その中で、まず1つが思った以上に誰もどこにもベンダーさんがいないなと。もっと言いますと、開発者はほぼ不在というのが現状です。これは制約条件なのです。御理解いただきたいのが、多分、皆様がお作りになっているので、非常に苦労されているのではないかと思います。FHIRは完全な実装をしようとしますと、①にあるFHIRステータスの話は今出てきたと思います。中島先生が非常に御丁寧にお話いただきまして、全くそのとおりだなと思っています。実際の例えばEBCと電カルの間でデータを取得する、交換するものを作ろうとしますと、まず電カルのほうが診療録の自由記載部分が多いので、ここをフォーマット化しなければいけないと。そもそもFHIRはリリース4の段階でNormativなもの、正式リリースのものは項目が非常に少ない。ゲノムに至ってはリリース後になってもまだ正式リリースではないという状態です。
当然、どういう項目を取得するかを考えなければいけないわけです。エンジニアとしては具体的にどういう項目を取得しましょうかということを設定しなければいけない。
次に、ここに書いてあるのは、デジタル、コンピュータの会話がコードで行われるわけです。これは仮ですが、1111とか2222とか数字ですが、何らかの符号で交換をするわけであって、患者氏名を患者氏名と会話するのは人間のほうですが、このコード体系が電カルごとに当然全然違うわけです。テクノロジーの分野は全く違う言語を話している。なので、患者氏名はA電カルからだったら1111、B電カルは3334だというふうなマッピングをしなければいけないわけです。このマッピング開発が非常に大変で、当然、マッパーを開発できるエンジニアは国内にほぼほぼいないのが現状です。本当に数社というのが現状です。
かつデータを正規化して変換しなければいけない。この③が実はかなり軽視されています。とんでもない労力になるわけです。ちなみに大江先生も大変だというお話を前にされていましたが、その後にもう1個我々の場合は交換サービス、中島先生がお話されたプラットホームを実際に2年か3年で仕上げなければいけないという立場で私の場合はありますので、交換サービスは何を使おうか考えなければいけない。そうなりますと、FHIRサーバーが今あるもので安定しているものはメールかファイル交換か、何でもできるのですが、何のサーバーを具体的に使えばいいのかということを考えなければいけないと。
ここまで出来上がったところで、実は結構強力な制約が出てくるのは、いろいろな製品を調べたり、技術を調べたり、マッパーを作るためのこういう技術はできるかなと思ったら、実は高い高い知財の壁がありまして、結構コストがかかるなと。これは良い技術ですが、とんでもないコストがかかるなと。そうなりますと、やはり、事業費の中には全く納まらないという問題が起きたりします。当然ですが、一部足りないところのマスターを購入しなければいけないという場合もありますので、これは今制度でもやっている電子処方箋等々でもありますが、用法と用量ではコード体系が当然違うというのは、山本先生のほうが当然お詳しいわけで、そういったことの観点で言いますと、私の場合どのコードを買ってくると幾らなのかとか、ここは公的でやってくださっているので、これを使おうかなということを選定していかなければいけない。それが⑤です。
⑥は、知財を整理した上でいよいよ今度は医療機関側にお願いをする。各病院でできるだけ閉域にシステムを構築しますから、その閉域で作ったものの中から一部データを取り出したものはデータをダンプすると言うのですが、取り出す領域を作らなければいけないのです。取り出す領域を作ったら、これは結構オープンのところにありますので、当然セキュリティ対策を病院でしなければいけないという問題が出てくると。コストは高いし、データダンプの領域のデータダンプサーバーを作るのは病院にやってもらえばいいのだろうか、どうかという問題に私の場合は悩みが深まると。①～⑦の技術者特有の問題が非常に多いことになります。当然、各病院と交渉したり、マップを作るエンジニアと話をしても、厚労省として、葛西の言っていることは分かるのだけど、厚労省としては本当に正式にそういうことをやっていく気なのでしょうかとか、そういう標準が何らかの形で認められるのでしょうかとか、費用負担はどうなるのかということを詰めていかないといけないというのが現状です。
今のような技術的な問題を解決しない限り、制度だけ作っても実は全く使われないという問題があります。手厳しいようですが、やはり期間であるとか、事業費用であるとか、開発者であるとか、人員、こういった事業のリソースの制約を先に把握しないと、幾ら話をしても成長過程は同じようにしか進まないのです。そういった事業的制約条件をどう把握するかというのは大きな課題だと思います。この辺りは是非皆様に御理解いただきたいと思います。
次のページですが、電子カルテの標準を作るということを考える際に、今日いらしている先生何人かとも前にお話をさせていただいたり、御指導を頂きながら私なりにも考えるところもあるのです。この電子カルテを標準化するとか、例えばクラウドを使うとかと言いますと、それは無理でしょうと言ったり、まあ、それはできるでしょうと言ってみたり、端的な感想的意見を多々受けるのですが、よくよく前向きに建設的に考えますと、電子カルテのコードをざっくりと書きました。必ずこうなっているわけではないのですが、システム上は今、医事会計と電子カルテというのは、サーバーとかデータベースが1つになっているものが多々あるわけですが、企業では余り変わりはなくて、まずベース系のシステムと医事系のシステムと人事給与、財務のようなバックオフィスがあり、サブシステム類がたくさんあります。これは膨大にぶら下がっている大病院もあれば、クリニックのような所はサブシステムがなかったりする所もあるわけです。そういったもののファンクションを整理しますと、実は連携の構造というのは、違う所とそれぞれ連携していることが分かります。
サブシステム系のことで言いますと、DICOM、ここにいらっしゃる先生は皆さんご存知だと思いますが、放射線等々、医療機器、検査機器類と連携するインターフェースですが、この機器連携を中心として成長してきたサブシステム類と、国のほうで整備してきた請求支払を、医事会計と請求支払の連携が強まっているという状態になります。今回初めてこの事業でやっとこの議論ができ始めたというのは、厚生労働省は非常に素晴らしいと私は思っております。電子カルテのベースシステムをFHIR等々で外部と連携することを考え始める。この左側の所がこれから新しく考える領域になります。
それとは別に、電子カルテベンダーさん特有には、院内のオーダリングが止まってしまうとまずいので、院内オーダーや各サブシステムとの連携APIというのは、これは各ベンダーさんは、ここを死守なわけです。ここが壊れると、院内システムは全部止まってしまうので、ここは全く変えたくないという思いが当然病院経営側もあるわけです。
そうなったときに、どこから標準化が可能なのかということを各国考えております。まず誤解があるのは、全部のシステムをただ1つのクラウドに乗せるということをしている国はどこにもないわけです。当然考えなければいけないのは、まず電子カルテのベースシステム類の中からどういったところが共通化できていくか。どうやって病院のタイプによって使いやすくできるかということを考えて、NHSにせよ、NHSはGPだけが電子カルテが標準化されていて、専門医療は電子カルテは標準化されていないわけです。これまでの全部の電子カルテをただ1つにするとか、しないとかという乱暴な議論はそろそろやめなければいけないと感じたりもします。
もう1つは、日本の場合は皆保険系のところです。イギリスは国営なので皆保険も何もないのですが、皆保険系の国々では実はプラットホームは医事システム系で作られたものを中心に成長することが多いです。シンガポールもHクラウドを構築しているのは、医事会計であったり、保険系であったり、あと認証プラットホームを作られている所が全てプラットホームを作っております。日本もいわゆる電子カルテ系のベンダーさんが集まってプラットホームを作ってくださいというのは成り立たないのではないかと感じております。やはり国がパブリックにプラットホームを構築するというのは、成長過程としては当然なのだろうと思います。その中で、上に乗せるアプリケーションといったものをどうやって標準化していくかということが、これからトライになるわけです。その中で、インターフェースを残しながら、正に院内オーダーのインターフェースであったり、危機連携のインターフェースを残しながら、左側のガイド連携のインターフェースを構築するという、この電子カルテ内の矛盾をどうやって整合性を取るかということを、早々に決めなければいけないと考えております。
次のページですが、その中で1つの案としては、大規模電カルのようなサブシステムが膨大にぶら下がって、私も何件も見せていただきましたが、そういった所を突然全てクラウドに乗せてどうこうというのは、余り現実的ではないというのが私自身の感想です。
一方、電子カルテが普及しない課題としては、小規模な診療所であったり、クリニックであったり、やはりコスト負担が大きいと。コストというよりもランニングコストの負担ではないかと思うのです。一時的に買って使い切れるのであれば使い切りますが、マスターが変わったり、何かする度に結構維持費用が掛かるとなると、それは紙のままでいいですとはっきり言われていた先生もたくさん私は伺っております。こういったところはできるだけクラウド電カルのようなものを活用しながら標準化が可能ではないかということです。そのようなものは当然有償なのか、無償なのかによって別途コントロールの費用が必要かどうかということを考えなければいけない。病院の中でもガバナンスが違うわけです。実は民間主体で運営されている病院、公的病院、日本の場合は国立病院があります。シンガポールはHクラウドは素晴らしいなと思われてしまうとまずいので、先に駄目な点を言いますと、シンガポールは実は民間病院はHクラウドは使っていません。公的病院だけがHクラウドに集約されていて、あとは意外ですが、老人ホームのような、いわゆる介護系の施設系に対して情報を提供する際にHクラウドを使っています。ガバナンスの違いが、自治体でもそうですが、東京都の病院経営本部がまず受け入れとしてのガバナンスを効かせる場合もあれば、基礎自治体病院の場合は、運営のスタイルが違うのは重々承知のはずです。こういったガバナンスの違いをよく解きほぐしながら、展開計画を作らなければいけないと思います。そういう意味では、まずクリニック、診療所のような所、国立、公的病院からどうやって標準化電カルが可能かどうかということを探るのが妥当だろうと思います。
一方、今日のメインテーマはそこではなくて、そういったことは当然厚生労働省の方がお考えになればいいことだと思いますが、マスターやAPIが今日のメインテーマだと思うのです。スタンドアローンであろうが、クラウド電カルであろうが、大規模電カルであろうが、例えば、私が着任してやっと報酬支払金等々、皆様には非常に御尽力いただいてチェックロジックを公開していただいて、いよいよ今度チェックロジックを病院の電子カルテにマスターとして提供することを検討していただいているようです。
そういった意味で言いますと、各病院でやっている標準チェックという行為、チェックロジックは、例えばそれぞれの病院が民生のソフトウェアを別に買ったりしているわけです。そういうことをやるぐらいであれば、公的チェックロジックを提供してあげたほうが多分いいだろうと思います。マスターも同じように、各団体で皆様非常に御尽力いただいて作ったものをできるだけ標準的に電カルにきちんと実装していかない限りは、なかなか進まないという課題があります。こういったマスターの展開とか、どうやって振らせるかというのは、制度として確立をしないとまずいと思います。例えばマスターも置いてあって、クラウドも置いてあって、そこからダウンロードするのか。それともどこからかダウンロードできなければCDで配布するのか等々、これは今電子処方箋の議論をしたり、その後続く国のサービスにおいても非常に重要な課題になってきています。
このマスター運営の問題が正に山本先生がやられたことの継続線上にありまして、せっかく作られたマスターがデジタル的にどういうふうに展開されて続いていくのか。マスターの維持はどうするのだということが、国自身がやられることは余りないかもしれませんが、独法であったり、特別民間法人であったり、いろいろな方の尽力において、公的にサステナブルな状態に持っていかなければいけないということが、今、大きな課題になっております。
次のページでもう1つ私がお伝えしたいのは、今日は情報処理推進機構という、医療分野では余り耳慣れないかもしれませんが、高倉先生はご存知で日々お世話になっていると思いますが、セキュリティの分野では国でやっている啓発の法人であり、研究の法人でもあります。あと産総研という、いずれも経済産業省界にある独立行政法人です。私は一応そこの研究員もやっておりますし、監視システムの構築もしています。IPAは独法全てのセキュリティ観測も、監視も運営をしているということは公表済みです。そういったシステムの構造を作ってきた身としては、ここはここで私は専門性がありまして、少し丁寧にお話をしたいと思います。
まずこの資料を御説明する前に、今日はせっかくなので、厚生労働省でまとめていただいている参考資料5をさっと見ていただきたいと思います。これは昨今、つい最近も、徳島の例はかなり頻繁に話題になって非常に大変だなと思いまして、その後復旧したというニュースも出ております。最初のページにIPAの、毎年出す重大脅威という、こういう脅威の順番に並んでいるわけではないです。一応、IPAの研究員としては説明をしておきたいのですが、これはこういうことが多発するということではなくて、トピックスとして、今年非常に多いなとか、話題になっているなとか、被害のインパクトが大きかったものが書かれているだけで、件数が多いわけではないのです。ただその中でも圧倒的に1位になっているのが、特に組織側のほうを見ますと、ランサムウェアの被害があります。これはシステムをロックして身代金を要求するという仕組みです。攻撃をするのは無作為にコンピュータが攻撃をしているのです。それどころか今はダブルクリックでランサムウェアサービスという、サービスというのは適切ではないかもしれませんが、ランサムウェアによっていろいな所から攻撃をして、身代金が取れるかという非常によからぬダブルクリックで簡単に攻撃ができてしまうようなサービスですらあります。それぐらい攻撃する側も特別な知識もいらないですし、今は機械が攻撃をしてきているということがポイントになるわけです。
次のページですが、その結果、昨今で起きているセキュリティインシデントをよく見ますと分かるのですが、一番最初の頃ウイルスが院内ネットワークにサーバーが侵入したり、古いものを使っていたのでこういうウイルスに感染したという、2015年ぐらいにあった問題があります。
それと昨今起きている、特に2018年ぐらい、宇陀市のインシデントぐらいから雰囲気が変わってきます。ウイルスが感染してから外部に接続されていないはずの医療情報システムが外部と接続された状況にあると。これはポイントなのです。閉域網だとか、スタンドアローンだから大丈夫だと言っていたはずなのに感染されているということがここで始まります。その後、執務用の端末から送られたマルウエアに感染しても取られてしまうとか、2021年千葉大学に至ってもフィッシングメールで、なぜメールを開けると取られてしまうのかよく分からないのに取られてしまう。そして、最近ではランサムウェアでシステムが止まっている。だんだん実は閉域網であっても問題なく攻撃ができているというところをよく御理解いただいたほうがいいということでお伝えしておくべきだと思います。閉域網であろうが、スタンドアローンであろうが、なぜか取られるという、仕組みは後でお話します。
次のページに、海外では最近どうなっているかということです。外部事業者によるミスが多いとか、内部不正で持ち出しが多い。これは分かりやすいところです。この右上の外部攻撃が圧倒的に増えてきているのは明らかです。その中でランサムウエア、マルウエアが非常に多いわけです。
次のページで、海外の事例は少し出したのですが、これはビットコインを要求して、身代金で実際に救急搬送をしなければならなくなり混乱をしたという例が、ハリウッドの病院でありました。それから、ドイツの病院ではシステム停止が起きてしまって、これも患者が受け入れられなくなったと。これは別の病院に搬送されて、実は関係ないという捜査当局の御意見があるようですが、これは因果関係はないかもしれませんが、残念ながらこれは搬送先でお亡くなりになるわけです。2021年には、アイルランドの公的医療サービスのプラットホームのシステムの一部、これはかなりの量がContiという、最近発生するランサムウエアを使う攻撃グループですが、攻撃してきて、一部どころか結構な量の外来患者の予約がキャンセルされてしまうということです。我々の業界で非常に有名ですが、「Apache Log4jという、最近の最新の脆弱性を使って攻撃をやっているのです。これは去年ぐらいから話題になって、脆弱性自体は5年前ぐらいからあるのですが、去年からこの脆弱性が非常に対応されて、アップデートを掛けても掛けても対応してくるという、非常に重要な脆弱性になります。
なぜこういうふうに四六時中攻撃ができて、四六時中何らかの脅威にさらされている状態になっているかということについて、NCSCという、これはイギリスのサイバーセキュリティセンターで、日本で言いますとNISCさんのような所になりますが、そこの年次レビューで、特にヘルスケアセクターの中で、ワクチンシステムをねらって攻撃してきている例が非常に多いです。何億ものドメインというサーバーが攻撃をしてきていますよということを報告しています。簡単に言いますと、機械が攻撃してきていることをまず理解しなければいけない。手で防御するのはもう100％不可能になってきています。
その中で、今日少し説明をしておきたいのは、この機械がたくさん攻撃をしてきていることを、我々はどう回避をしなければいけないのかということです。各病院でその機械で攻撃をしてきているような者に防御できる体制を作るのは多分無理ではないかと思います。当たり前ですが、一般診療所・クリニック等では無理で、少し絵で言いますと、悪意があるサーバーがこの機械で攻撃をしてきている中で、我々は今までネットワークのセキュリティを防御し続けたのです。ところが、最近クラウド側に上がってきていて、クラウドとネットワークというのは密接に連携していません。クラウドはクラウドで仮想化された情報に置き換えられるので、機密ネットワーク上にクラウドを置いても、クラウドはネットワーク内の挙動は一切見えないという、ここが非常に大きな脆弱性になります。この脆弱性をついて、クラウドであろうと何であろうと攻撃をしてくるというのが多いわけです。
閉域網なのになぜか使われるというのは、メールなり、一般ネットワーク側から分離しても実はUSBとか、ファイルをブリッジするサーバーで、名簿を受け渡しているということがあって、結局そこから侵入してしまうという。100％防御してもやはりコンピュータウイルスがそうなのですが、どこかで入ればどんどん蔓延するというわけで、100％一般ネットワークと機密ネットワークが分離しますと、実は仕事ができない。仕事ができないので、やはり生活ができないのですから、つないでしまっているのが現実です。そういう意味で言いますと、現実に起きているコロナと一緒のようなことになります。
これを対処するためには、攻撃手法を察知することや、挙動を察知することが大事になっているのではないかということをお伝えしておきたいと思います。上の層に対策をしなければいけないということです。
最後に簡単にまとめたいと思います。最後のページですが、そういう意味ではまず事業的な制約条件であるとか、開発の本数、開発能力を理解しなければいけないというところを書きました。最後に、セキュリティの監視もできるだけ集約しておくほうがいいのではないかと。逆に病院側も遮断等に集中するほうがいいのではないかとお伝えしておきたいということです。大体私からは以上です。
○中島主査 葛西先生、大変分かりやすい説明をありがとうございました。時間がありませんが、何か御質問などありませんか。
○高倉構成員 多分、ここは私が発言しないと駄目だろうと思いますので、1つは、今回ここで議論している中で、例えばサイバー攻撃を受けたときに、クリニックの電カルシステムが駄目になってしまう。今回の半田病院とかは正にそうですが、その際に、こういうFHIRで、ある意味バックアップを持っている仕組みですね、クリニックが駄目になっても必要最小限のデータは中央、クラウドにあるというバックアップの体制が取れるようにしておく必要があると。これは正に書かれているとおり、システム、資源を集中しておく必要があるかと感じました。
もう1つは、先ほど言われたのは、保守用とかいろいろ言われましたが、一番の問題は保守用の入口が、私たちセキュリティ屋が持っているインターネットにつながっているというのと、クリニックの方がイメージしている保守業者しか入ってこない勝手口というイメージのギャップを埋めていかないと、多分、認識が合わないまま話がずっと平行線をたどっていると今考えています。以上です。
○中島主査 松村構成員、手短にお願いします。
○松村構成員 2点あります。非常に整理してお話いただきましてありがとうございます。最初のほうで、実際に病院、クリニックが扱っている情報は非常に多岐にわたって、それをどういうふうに扱うのかという問題提起を頂きましたが、正にそこの整理が今回必要だと思います。医療従事者側から見ますと、病院のシステムで扱っている、いわゆるオーダーリングシステムは、その都度その都度の業務のための情報伝達であって、外部と情報連携しないといけないようなものではないと思います。情報連携するのは病歴的な情報です。患者さんの病態を表す情報を取る扱う必要があって、今回のターゲットもそこに絞るべきだと思います。この観点で、しっかり整理する必要があると思いました。
後半のセキュリティの話ですが、正に先生がおっしゃっているとおり、高度な脅威があって、一方でこういうネットワーク医療をやろうとしますと、必然的に電子カルテをネットワークにつながないといけないことになります。これを各医療機関で責任を持ってやりなさいと言っても限度があります。電子カルテシステムそのものがクラウドに出ていくことを前提に作られていて、そのクラウドのシステムが更に外部に接続するときにベンダーさんのほうでしっかり守ってくださいといった方法で、技術を集約させる構成にしていくのが良いと思います。以上です。
○葛西参与 私も全く同じ意見です。
○中島主査 ありがとうございます。それでは時間になりましたので進めさせていただきます。葛西先生、ありがとうございました。以上で本日の議題は終了となります。最後に全体を通して御意見、御質問などありましたらお願いします。
それでは、ほかに御意見などがなければ、本日はこれまでとさせていただきます。事務局からそのほかに何かあればお願いします。
○田中室長 本日も活発な御議論を頂きまして、ありがとうございました。また非常に多くの先生方から内容のある御発表を頂いて感謝を申し上げます。本日の会議につきましては、議事録を可能な限り速やかに公表できるよう、事務局として校正作業を進めてまいります。構成員の皆様におかれましても、御多忙中とは存じますが、御協力を頂きますようお願い申し上げます。次回のワーキンググループの日程については、日程が決まり次第御連絡をさせていただきます。どうぞよろしくお願いします。本年もどうぞよろしくお願いします。事務局からは以上です。
○中島主査 本日はこれで閉会といたします。活発な御議論をありがとうございました。
