クラウド電子カルテ事業者によるリスク・コミュニケーションの実践と課題 / risk-communication

医療ISAC Security Lecture 2023 #008 にて株式会社ヘンリーの戸田が、ガイドラインで求められる事業者と医療機関とのリスクコミュニケーションについて、解説した際の発表資料です。

https://m-isac.jp/2023/11/13/sl202308/

Transcript

1. Copyrights(c) Henry, Inc. All rights reserved. クラウド電子カルテ事 業者による リスコミの 実践と課題 2023/Nov 医療ISAC Security Lecture
2. Copyrights(c) Henry, Inc. All rights reserved. 発表者の紹介 Kengo TODA 株式会社ヘンリー所属。医療情報技師。SRE（Site Reliability Engineer）としてクラウド型電子カルテ・レセコンシステム 「Henry」の信頼性向上につとめています。 お客様が医療DXを推進するために必要な3省2ガイドラインの 対応や、リスク・コミュニケーションの実践も 推進しています。 2
3. Copyrights(c) Henry, Inc. All rights reserved. 本日のねらい 各種ガイドラインが求める事業者と医療機関におけるリスク・コミュニ ケーション（リスコミ）について、なぜ必要なのかを確認します。また実 践を通じてどのような課題が生まれ、どのように解決したかをご紹介し ます。 医療機関と事業者のどちらに所属する方にとっても、リスコミの優先度 決定や対応プロセスの参考にしていただけます。 3
4. Copyrights(c) Henry, Inc. All rights reserved. 資料と質問について 資料は弊社公式ページから配布予定です。 https://speakerdeck.com/henryofficial/ 最後にまとめて質疑応答の時間を取りたいと思いますので、 疑問等についてはお手元に書き留めておいていただけますと 幸いです。 4
5. Copyrights(c) Henry, Inc. All rights reserved. アジェンダ 1. リスク・コミュニケーションとは 2. どこからリスク・コミュニケーションを始めるか 3. サービス導入キックオフの時点でリスコミを始めよう 4. 事例の紹介 a. アカウント管理 b. リモート保守 c. 職員教育 d. 外部システム連携 e. 立入検査対応 5. まとめ 5
6. Copyrights(c) Henry, Inc. All rights reserved. リスク・コミュニケーションとは事業者と医療機関が合意形成をすること “対象事業者は、自らが提供する医療情報システム等の安全管理に 係る説明義務を果たし、医療機関との共通理解を形成するために、医 療機関等に対して第 4 章で情報提供すべき内容として示した事項を 含む必要な情報を文書化して提供すること。 具体的には、5.1.5 で作成した「リスク対応一覧」や後述の運用管理 規程に定められた事項に係る情報提供を通して、医療機関等との役 割分担、対象事業者として受容したリスクの内容等について、医療機 関等と合意形成すること。” 出典：医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 第 1.1 版 5.1.6. (1) 医療機関等とのリスクコミュニケーションの実施 (33p) ※強調は引用者による 6
7. Copyrights(c) Henry, Inc. All rights reserved. リスク・コミュニケーションをするとなにが嬉しいか リスコミを行うことで、医療を持続的に提供するうえでのリスクを事前 に発見できます。 加えて発見されたリスクに対しどう対応するかを医療機関と事業者の 間で協議することで、有事の初動が素早くなります。 7
8. Copyrights(c) Henry, Inc. All rights reserved. リスク・コミュニケーションを行わなかった事例（１） 「医療情報を取り扱う情報システム・サービスの提供事業者における 安全管理ガイドライン 第 1.1 版」にコラムが掲載されています。 医療機関と事業者の間で互いに「これは相手がやるだろう」と思って いる状態になると、有事の際に迅速な対応が取れず、被害拡大にブ レーキをかけることも、証拠保全も、診療再開のための活動もできな い可能性が残ります。 8
9. Copyrights(c) Henry, Inc. All rights reserved. リスク・コミュニケーションを行わなかった事例（２） このコラムが触れた事例では、2021年10月31日（日）朝８時にランサ ムウェアの感染確認が取れていたにも関わらず、システム事業者との 協議は11月2日（火）11時以降の開催でした。 またこの事業者は2021 年 10 月 12 日にサポートが終了していた Silverlightを医療機関に説明せず利用を継続していたことも判明して います。 他にもVPN装置やサポートが終了していたWindows Serverをシステ ム担当部門に説明せずに設置した事例が知られています。 9
10. Copyrights(c) Henry, Inc. All rights reserved. 必要性は理解した、でもどうやって？ 10
11. Copyrights(c) Henry, Inc. All rights reserved. どこからリスク・コミュニケーションを始めるか 厚生労働省が提示するものを議論の基盤として利用できます。 1. 医療機関におけるサイバーセキュリティ対策チェックリスト 2. サービス事業者による医療情報セキュリティ開示書（SDS） SDSは医療情報を取り扱う情報システム・サービスの提供事業者に おける安全管理ガイドラインでも「リスク対応一覧」を代えられる書類と して記載されています（32ページ）。 つまり事業者から医療機関に対してあらかじめ提出すべき書類のひと つとして扱われています。 11
12. Copyrights(c) Henry, Inc. All rights reserved. 早い段階でリスク・コミュニケーションを始めよう 医療情報を取り扱う情報システム・サービスの提供事業者における安 全管理ガイドライン 第1.1版では「医療機関等に対して（中略）必要な 情報を文書化して提供すること」を求めています。 このため事業者は、契約書、合意書、利用規約などの文書に必要な 情報を記載してご説明にあがる必要があります。 また導入プロジェクトのスコープやコストに影響を及ぼすことも考えら れるため、契約締結時やサービス導入の最初期などにご説明するこ とが望ましいでしょう。 12
13. Copyrights(c) Henry, Inc. All rights reserved. 医療機関様によりリスコミは変化する ひとくちに中小病院と申し上げましても、様々な医療機関様が いらっしゃいます。院内に責任者が不在な場合から、すでに洗練され た情報システム運用がされている場合まで様々な状況が 考えられるため、事業者側も医療機関様に合わせた対応が必要と考 えます。 13
14. Copyrights(c) Henry, Inc. All rights reserved. 想定される医療機関様の状況の例 院内システム担当者が定まっていない 院内システム担当者が定まっている 医療情報システム安全管理責任者などが定まっている システム運用管理規程が定まっている 事業継続計画書 （BCP）が定まっている 端末やアカウントが集中管理されている ゼロトラストがシステム運用の前提になっている 14 ※分類はイメージです
15. Copyrights(c) Henry, Inc. All rights reserved. 状況に応じた事業者から見たリスク 院内システム担当者が定まっていない 院内システム担当者が定まっている 医療情報システム安全管理責任者などが定まっている システム運用管理規程が定まっている 事業継続計画書 （BCP）が定まっている 端末やアカウントが集中管理されている ゼロトラストがシステム運用の前提になっている 15 ※分類はイメージです 担当者がいない 言った言ってない問題の可能性 代行入力などの運用規定がない 緊急時の連携が取れない
16. Copyrights(c) Henry, Inc. All rights reserved. 状況に合わせて必要な対応も変わる 院内システム担当者が定まっていない 院内システム担当者が定まっている 医療情報システム安全管理責任者などが定まっている システム運用管理規程が定まっている 事業継続計画書 （BCP）が定まっている 端末やアカウントが集中管理されている ゼロトラストがシステム運用の前提になっている 16 システム運用管理規程の雛形を提供 システム運用のご提案 既存規程等とのすりあわせ 既存規程などの更新 ※分類はイメージです ご提案する 解決を 調整する
17. Copyrights(c) Henry, Inc. All rights reserved. この観点からも、まずはチェックリストをしっかりやることが肝要です 院内システム担当者が定まっていない 院内システム担当者が定まっている 医療情報システム安全管理責任者などが定まっている システム運用管理規程が定まっている 事業継続計画書 （BCP）が定まっている 端末やアカウントが集中管理されている ゼロトラストがシステム運用の前提になっている 17 医療機関におけるサイバー セキュリティ対策チェックリスト 令和5年度分 対応範囲 ※分類はイメージです リスコミを進める前にチェックリストを使ってセル フチェックをしておきましょう
18. Copyrights(c) Henry, Inc. All rights reserved. 事例の紹介 リスコミとは何でありどうしてやると嬉しいのか、どのように始めるかを見てきまし た。これからリスコミを実際に始めていきますが、様々な要点に対して様々な観点 から考えるため、場合によっては知らない着眼点もあるかもしれません。浅く広く 話すことで敷居を下げられれば幸いです。 18
19. Copyrights(c) Henry, Inc. All rights reserved. 事例 アカウント管理 医療機関にはフルタイムで勤務される方から、非常勤やバイトまで様々な 形態の職員がいらっしゃいます。法律で有資格者しかできない業務が定められて いることもあり、アカウント管理は難度・重要度ともに高いことが特徴です。 19
20. Copyrights(c) Henry, Inc. All rights reserved. 共用アカウントの利用をやめよう 受付用アカウントを受付スタッフで共有したり、代行入力のために医師 のアカウントを医師でないスタッフが使ったりという運用が考えられま す。また退職者のアカウントを新しく配属されたスタッフに割り当てる 運用も考えられます。 これは医療情報の真正性を保つ観点からも、情報セキュリティの観点 からも、望ましくないため避けるようにします。 もちろんガイドラインにも記載があります（医療情報システムの安全管 理に関するガイドライン 第6.0版 Q&A 企 Q－44）。 20
21. Copyrights(c) Henry, Inc. All rights reserved. 付箋でパスワード管理する危険性 個別にアカウントを管理すると、各職員にパスワードを管理する責務 が生じます。またガイドラインではパスワードに十分な強度を求めてい るため、他のサービスで利用していない充分に長いパスワードを使う 必要もあります。 こうしてパスワードを付箋で利用端末に貼る、という動機が生まれま す。職員教育や就労環境観察を通じてこれをなくしていく必要がある でしょう。 21
22. Copyrights(c) Henry, Inc. All rights reserved. 事例 リモート保守 VPN装置の脆弱性ならびに粗雑な管理によって、リモート保守が攻撃者にとって の攻撃機会となっているのはご存知のとおりです。事業者と医療機関の間で「ど のようにリモート保守を行うか、そのリスクはなにか」きちんと話し合いましょう。 22
23. Copyrights(c) Henry, Inc. All rights reserved. VPN装置メンテナンスは誰がやる？ 各種報道を見て、まず注目されるのは「なぜVPN装置の脆弱性が放 置されたのか」です。 - 電子カルテ事業者が持ち込んだので事業者が保守するべき - 院内ネットワークの一部なのだからNW業者が保守するべき - 医療機関の資産なので医療機関が管理するべき 様々な考え方があると思われます。貴院ではどのようにお考えでしょ うか。そのお考えには各事業者が同意されていますか。 23
24. Copyrights(c) Henry, Inc. All rights reserved. 責任分界点を明確にしよう 責任分界点とは、どこからどこまでが誰の責任かを切り分ける 境界です。責任分界の詳細は医療情報システムの安全管理に関する ガイドライン 第6.0版の企画管理編２．に記載があります。 例えばリモート保守の場合、以下について検討が必要です。 - インターネット回線 - 利用するソフトウェアやVPNサーバなど - 利用するソフトウェアのユーザやパスワード - 利用するソフトウェアが稼働するOS - 利用するソフトウェアが稼働するハードウェア 24
25. Copyrights(c) Henry, Inc. All rights reserved. リモート保守は攻撃の経路になります リモート保守は問題を迅速に解決するとともに、保守にかかる金額を 抑えひいては医療費を抑えるために重要です。しかし過去の事例から も明らかなように、攻撃の糸口として使われることも多々あります。 リモート保守を安全なものとするためには、事業者と医療機関 双方の運用が重要です。リスクを認識いただき、何が必要かを 事業者と協議ください。 25
26. Copyrights(c) Henry, Inc. All rights reserved. 弊社における責任分界点の事例 26 対象 責任分担 利用するクラウドサービスの維持管理 弊社（電子カルテ事業者） インターネット 医療機関様 利用するソフトウェアの維持更新 医療機関様 利用するソフトウェアのワンタイムパスワード 医療機関様 利用するソフトウェアの稼働するOS 医療機関様 利用するソフトウェアの稼働するハードウェア 医療機関様
27. Copyrights(c) Henry, Inc. All rights reserved. 説明さしあげている内容の例 27 対象 責任分担 利用するクラウドサービスの維持管理 弊社（電子カルテ事業者） インターネット 医療機関様 利用するソフトウェアの維持更新 医療機関様 利用するソフトウェアのワンタイムパスワード 医療機関様 利用するソフトウェアの稼働するOS 医療機関様 利用するソフトウェアの稼働するハードウェア 医療機関様 ひとつのワンタイムパスワードを 複数の事業者に提供することは 避けてください。 ワンタイムパスワードが悪意ある人に 見られないよう、端末を離れる場合はWindows の画面をロックしましょう。 リモート保守が完了したら リモート保守に必要なソフトウェアを 終了させてください。
28. Copyrights(c) Henry, Inc. All rights reserved. 補足 職員教育 先ほどから「事業者としてシステム担当者にこう説明します。医療機関様は職員 教育をお願いします。」と何度か申し上げています。これについて、補足をします。 28
29. Copyrights(c) Henry, Inc. All rights reserved. なぜ職員教育が重要なのか どんなにシステムやネットワークが素晴らしいものでも、職員の「使い 方」に問題があると様々な問題が発生します。 - 生産性が上がらない - 情報の漏洩が発生する - カルテの真正性など、求められる要件を満たせない ここで「使い方」とは規定で定めた運用だけでなく、職員のリテラシーも 含んでいます。これを底上げするために職員教育が重要です。 29
30. Copyrights(c) Henry, Inc. All rights reserved. 大学病院の委託先が情報漏えいをした事例も “受付業務の委託先（中略）の社員（当時、以下 元社員Ａ）が、患者様 1名の診療情報を故意に外部に流出させたことが発覚しました。 元社員Ａは、業務中に友人である患者Ｂ氏が当院を受診したことを知 り、スマートフォンを用いて氏名、生年月日、診察記録が記載された電 子カルテを表示したパソコン画面を動画で撮影し、共通の友人である C氏にSNSを通じて送信しました。” 近畿大学病院で発生した診療情報の流出事案について ※強調は引用者による 30
31. Copyrights(c) Henry, Inc. All rights reserved. 教育や訓練によって情報の漏洩リスクを下げられます 医療提供者が起こした個人情報漏え いの事故原因に関する研究（大分県 立看護科学大学）でも”規定の整備な どの組織的安全管理対策の見直し、 従業員や委託先に対しての教育・訓練 といった人的安全対策の実施”が有効 なケースがあるとしています。 31
32. Copyrights(c) Henry, Inc. All rights reserved. 職員教育は手間がかかるが、事業者での完結は現実的ではない 事業者側で職員教育の一部を引き受けることや、コンテンツを提供す ることは可能だと考えます。特にサービス固有のリスクについては実 装や制約にもっとも詳しい事業者がコンテンツを作成することが適当 でしょう。 一方で職員教育は実施だけでは終わらず、その後の経過観察も重要 です。職員の行動を変えられたか、変わらないならどう働きかけるか は、事業者による実行・決断が難しい領域です。 32
33. Copyrights(c) Henry, Inc. All rights reserved. 医療機関様の負担を減らすためにできる工夫 幸い厚生労働省が「医療機関向けセキュリティ教育支援ポータルサイ ト」（MIST：Medical Information Security Training）を公開しており、 教育コンテンツを流用できます。 また情報処理推進機構（IPA）も教育用コンテンツを多く出しており、IT パスポートのような資格試験も提供しています。医療情報技師育成部 会の「病院情報システムの利用者心得」も職員教育に役立つでしょ う。 まずはこういった既存コンテンツを流用し、職員教育サイクルを回し始 めることから始めてみてはいかがでしょうか。 33
34. Copyrights(c) Henry, Inc. All rights reserved. 事例 外部システム連携 医療情報システムは必ず連携して動作します。単独で動作するシステムはありま せん。各システムは異なる事業者から提供されるため、システム 連携には事業者の壁を超えたコミュニケーションが必ず必要です。このため認識 の齟齬による責任分界点のあいまい化に注意を払ってください。 34
35. Copyrights(c) Henry, Inc. All rights reserved. 事業者と事業者の関係性 「医療情報を取り扱う情報システム・サービスの提供事業者における 安全管理ガイドライン 第1.1版」に医療情報システム等の代表的な提 供形態についての記載があります。 大きく分けて「1 社で提供するケース」「複数の事業者が提供するケー ス」そして「医療機関等が複数事業者と契約するケース」が説明されて います。 35
36. Copyrights(c) Henry, Inc. All rights reserved. 事業者と事業者のコミュニケーション 弊社のようなクラウド型電子カルテの場合「医療機関等が複数事業者 と契約するケース」が最も近いものとなります。この場合、事業者間に は相互に選定・管理を行う関係にはありません。 医療機関にて各事業者が提供する機能や APIを知り、連携方法を検討することが 必要になります。 まず各事業者の責任分界点を明確にする ことが、有事の際に事業者間調整に 工数を取られる事態を予防するためにも 有効です。 36
37. Copyrights(c) Henry, Inc. All rights reserved. 連携に用いる端末における権限管理 共有ファイルシステムを用いたファイル連携を行う場合、その共有ファ イルシステムには複数の端末（ユーザ）が読み書きを行えることから、 情報漏洩の機会となりやすいはずです。 共有ファイルシステム周りはファイアウォールの設定も複雑化しやす い傾向です。管理権限やアクセス権限は慎重に設計します。 複数のネットワークをハブのように繋ぐ構成になることもあり、攻撃に さらされやすいことに留意します。 37
38. Copyrights(c) Henry, Inc. All rights reserved. 事例 立入検査対応 保健所による立入検査が実施された場合、医療情報システムの事業者はこれを サポートすることが必要です。 38
39. Copyrights(c) Henry, Inc. All rights reserved. 保健所による立入検査でチェックリストが使われます 医療機関におけるサイバーセキュリティ対策チェックリストは 実際に立入検査で利用されています。 チェックが入らない項目をどう改善していくかを考え説明する 必要が生じるため、まだ立入検査が来ていない医療機関様に おかれましても、先手を打ってチェックリストを使い自発的に 確認を進めることをおすすめします。 39
40. Copyrights(c) Henry, Inc. All rights reserved. 事業者は医療機関にSDSを提出して内容を説明しよう 先述の通り、事業者は医療機関に対してサービス事業者による医療 情報セキュリティ開示書（SDS）あるいはこれに準ずる資料を提出する 必要があります。事業者は予めチェックリストに記入しておき、医療機 関の求めに応じて提出できるようにします。 SDSの記入と参照にはJAHISから公開されているユーザーズガイドを 参考にしてください。 40
41. Copyrights(c) Henry, Inc. All rights reserved. まとめとふりかえり リスコミとは何で、どうしてやる必要があるのか、その恩恵は何かを見てきました。 また事例をいくつか見ることで、どのような心持ちでどうコミュニケーションするか が見えてきたのではないかと思います。 41
42. Copyrights(c) Henry, Inc. All rights reserved. まとめ • 事業者と医療機関は、ともにリスク・コミュニケーションや責任分界 点の明確化を積極的に進めるべきです。 • 報告書から失敗事例を学べます • SDSやチェックリストがとても役に立ちます • 職員がどう業務を回しているかを見ることが大切です。 • 規程やマニュアルに定めていることができているか • 「付箋にパスワード」などの兆候がないか • 実情に合う職員教育を実施できているか 42
43. Copyrights(c) Henry, Inc. All rights reserved. 医療機関の皆さんが明日からできること 事業者とコミュニケーションすべきリスクを知るために、 1. 「医療機関におけるサイバーセキュリティ対策チェックリスト」を2年 分埋めてみる 2. 事業者に「サービス事業者による医療情報セキュリティ開示書 （SDS）」を提出するように求める 3. 事業者と協議して責任分界点を明確にする 4. 協議結果と「医療情報システムの安全管理に関するガイドライン」 を踏まえてシステム運用管理規程を作成する、または見直す 43
44. Copyrights(c) Henry, Inc. All rights reserved. 情報システム運用規程が整ったら… 情報システム運用規程の整備が不備なく完了していることを医療 ISAC規定認証や医療ISAC監査認証をもって確認することで、まだコ ミュニケーションしていないリスクを発見する一助になると期待できま す。もちろん医療機関として情報システムの安全性を高めるためにも 有効です。 また攻撃を想定したガイダンスも出ていますので、チェックリストだけ では不足する課題を洗い出しに活用できます。 - 医療機関向けランサムウェア対応検討ガイダンス - 医療機関向けサイバー攻撃（情報窃取/ウェブ改ざん攻撃）対応検 討の手引き 44
45. Copyrights(c) Henry, Inc. All rights reserved. 事業者の皆さんが明日からできること 医療機関とコミュニケーションすべきリスクを知るために、 1. 「医療機関におけるサイバーセキュリティ対策チェックリスト」を2年 分埋めてみる 2. 「サービス事業者による医療情報セキュリティ開示書（SDS）」を作 成して提出する 3. 医療機関や関係事業者と協議して責任分界点を明確にする 4. TODOが見えてくるので開発計画などを進める 45
46. Copyrights(c) Henry, Inc. All rights reserved. 弊社が認識している今後の課題 - 職員教育コンテンツの提供（前述） - 運用パターンご提案の強化 - 事業継続計画書 （BCP）ひな形の提供 - 令和6年度の「医療機関におけるサイバーセキュリティ対策チェックリスト」 で求められているため - 導入済み医療機関様にアップデートされた情報を届けるすべ - 技術や機能のアップデート、弊社の経験蓄積に応じてリスコミの内容は増 えていくはず - 関連機能開発など 46
47. Copyrights(c) Henry, Inc. All rights reserved. Q&A ご質問がございましたらお願いします。 47
48. Copyrights(c) Henry, Inc. All rights reserved. こちらは各所で指摘されている通りだと考えます。 ただリスクは改定や補助金を待ってくれないため、優先度をつけてや れるところから対応を進めるべきです。 今回は中小規模を想定して優先度について話しましたが、もし 話が壮大にすぎると感じられた場合は医療情報システムの 安全管理に関するガイドライン第6.0版に付属の小規模医療機関等向 けガイダンスも参考にされると良いかもしれません。 人材・資金の面で対応が難しい 48
49. Copyrights(c) Henry, Inc. All rights reserved. 責任分界点は役割分担のため？ 少々異なると考えています。もちろん紛争に備え役割を明確にすると いう性格も無いではないですが、より患者様の情報を守るための連携 を可能にする方が重要です。 例えば「衛る技術」の価値を最大化することを目指しているハードニン グプロジェクトでは、その「HARDENING宣言」の中で以下を表明して います： 2. それは、強固な計画よりも柔軟な変化を必要とする。 3. それは、役割分担よりも連携と協働を必要とする。 状況に応じた柔軟な連携と協働を実現するため、リスコミをご活用くだ さい。 49
50. Copyrights(c) Henry, Inc. All rights reserved. 二要素認証（2FA）はどう選定するか 新医療2023年1月号に、特集「実効的二要素認証の要諦と課題」が 掲載されています。 手袋着用時に利用できるか、などの医療現場特有の要件を踏まえた 分析が行われているため、これからの導入を検討されている場合は 一読をお勧めします。 50
51. Copyrights(c) Henry, Inc. All rights reserved. 画像素材について 一部画像素材はいらすとや様よりお借りしました。 51
52. Copyrights(c) Henry, Inc. All rights reserved. 株式会社ヘンリーは社会課題解決を目的に設立されたスタートアップです https://corp.henry-app.jp/ 52