医療管理者が知っておきたいITセキュリティの基本——クラウドかオンプレかより先に考えること

訪問看護師として働きながら、私は残薬管理アプリを個人開発しています。

開発を続けていると、職場の上司や管理者から、こんな言葉をもらうことがあります。

「クラウドって、個人情報が漏れないの？」
「やっぱりオンプレのほうが安全じゃないの？」

正直、この不安はよくわかります。

医療や介護の現場では、患者さんに関わる情報を扱います。だからこそ、「外部のサービスを使って本当に大丈夫なのか」と慎重になるのは、むしろ当然の感覚です。

ただ、その一方で、私は少し違和感も持っています。それは、

という話に寄りすぎてしまうことです。

セキュリティとは、単に「どこに保存するか」ではなく、誰が、どの権限で、どの情報にアクセスできるかを設計することだと思っています。

この記事では、私が開発している残薬管理アプリの実装をもとに、医療ツールのセキュリティ設計がどのように実現されているかを解説します。

エンジニアでなくても理解できるように、できるだけ現場の言葉に置き換えながら書いていきます。

1. まず知っておきたい：セキュリティには「2種類」ある

医療現場でITが話題になると、「ファイアウォール」「VPN」「クラウド」などの言葉が出てきます。

でもこれらは、全部ひとまとめに「セキュリティ」と呼ばれているだけで、守っているものが違います。

大きく2つに分けられます。

ネットワークセキュリティ

→ 「そこまで来られるか」を守る

アプリケーションセキュリティ

→ 「来た人が中に入れるか」を守る

建物に例えると、こうなります。

【外の道路】

↓

【門・フェンス】← ネットワークセキュリティ

↓ 突破された

【玄関の鍵】← 認証（あなたは誰か確認）

↓ 解錠された

【部屋ごとの鍵】← 認可（どの部屋に入れるか）

↓

【防犯カメラ・入退室ログ】← 操作ログ（誰がいつ何をしたか記録）

どちらかだけ強くても、意味が薄い。

門を固くしても、玄関が無施錠なら誰でも入れます。

玄関を固くしても、部屋の鍵がなければ、入った人が何でも見られます。

医療現場の「クラウド怖い」という感覚は、主にネットワークへの不安です。でも実際に医療情報を守るために重要なのは、その先——アプリケーションの設計です。

2. 「よく聞く言葉」の正体

よく耳にするセキュリティ用語が、どちらの層の話なのかを整理しておきます。

ここで一つ、大事な話があります

IP制限は「このIPアドレス（場所）からしかアクセスできない」という制限です。自宅や職場の固定回線なら使えます。でも、スマートフォンのテザリングやカフェのWi-Fiはアクセスのたびにアドレスが変わるため、訪問看護師など移動を伴う職業のセキュリティ管理は、IP制限だけに頼ると運用が難しくなります。

より実用的なのは、多要素認証（MFA）です。

多要素認証とは、パスワードに加えて「スマートフォンに表示される6桁のコード」など、もう一つの確認手段を組み合わせる方法。あのめんどくさい2段階認証というやつです。どのネットワークから来ても有効で、パスワードが漏れただけでは侵入できない状態を作れます。

1年ほど前、中小の病院がサイバー攻撃を受けた事例がありました。その際に、多くの分析がされ問題が浮き彫りになりました。その病院は、パスワードでログインした後、誰でもそのパソコンからであればアクセスできる状態のまま放置されていたのです。

でも、これ、ほとんどの病院がそうではないですか？

idとパスワードは保存されており、エンターを押せば入れる仕様になっていませんか？

3. クラウドのネットワーク層は「誰が担うか」

このアプリは React + Supabase（データベース）+ Vercel（公開サーバー）という構成です。

ネットワーク層のセキュリティは、ほぼクラウドプロバイダー（クラウド上のサーバーやデータベースを提供・管理している会社。たとえば Supabase や AWS、Google Cloud など）が担ってくれています。

Supabase のデータベースはインターネットから直接アクセスできない場所にあります。Supabase の API を経由しないと、そもそも届かない設計です。

つまり「クラウドは怖い」の実態は多くの場合、設計が見えない、どこからでもアクセスできるんでしょうという不安 です。実際には、適切なクラウドサービスの方が、オンプレの社内サーバーよりも厳密にネットワーク分離されていることもあります。

怖いのはクラウドかオンプレかではなく、設計がされているかどうか です。

4. このアプリが実装したセキュリティ設計

ここからは、アプリケーション層——つまり設計次第で大きく変わる部分の話です。

残薬管理アプリで実装しているセキュリティは、5つの層に分かれています。

① 情報の最小化——入力できない設計

セキュリティの一番の基本は、「守る情報を減らすこと」です。漏れたら困るデータは、最初から持たない。

このアプリに登録できる情報は、こうなっています。

登録できる情報：

- 利用者のニックネーム（「Aさん」「田◯さん宅」など）
- 薬の名前・残数・タイミング
- 受診予定日・医療機関名

登録しない情報：

- 利用者の氏名・住所・連絡先・生年月日
- 診断名・病名

単体で個人を特定できる情報を最初からシステムに存在させないのが最初の設計方針です。

複数の準個人情報で個人が特定されない程度に設計しようと考えているためニックネーム部分の運用も今構築中です。

データベースの定義レベルで、氏名・住所を入力するフィールドが存在しないようにしています。画面で禁止するより強い制約です。画面を迂回してAPIを直接叩いても、テーブルに存在しないカラムには何も入れられません。

② 認証——誰がアクセスするか

認証とは「あなたは誰ですか」を確認することです。
このアプリはメールアドレスとパスワードでログインします。ログインのコードはこうなっています。

ここで大切なのが、パスワードの保存方法です。

入力したパスワードそのものは、データベースには保存されません。

たとえば `password123` というパスワードを登録しても、データベースには `$2a$10$...` のような意味のわからない文字列として保存されます。

これは bcrypt という仕組みで変換されたもので、元のパスワードには戻せません。

ログインするときは、入力されたパスワードをもう一度同じ変換にかけて、保存されている文字列と一致するかを確認します。

ログイン成功後は、JWT（JSON Web Token） というデジタル証明書が発行されます。以降のアクセスでは、このトークンを提示することで「ログイン済み」と判断されます。

③ 認可——誰がどのデータを見られるか

ここが最も重要な設計です。

「ログイン済み」イコール「全データ見放題」では困ります。

このアプリは複数の事業所が同じデータベースを共有します。A事業所のスタッフが、B事業所のデータを見られてはいけない。

③-1. 事業所ごとのデータ分離：RLS（行レベルセキュリティ）

Supabaseでは、データベーステーブル(PostgreSQLのテーブル)を窓口(REST API経由)で操作できます。

これは、API経由でデータを書き換えられる便利な仕組みですが、医療ツールとして使う場合は慎重な設計が必要です。画面上では見えないようにしていても、データベース側に制限がなければ、リクエストの作り方によって本来見えてはいけないデータにアクセスできてしまう可能性があるからです。

そこで使っているのが、PostgreSQLの RLS（Row Level Security） です。

RLSは、テーブルの行ごとに「誰が読めるか」「誰が追加・更新できるか」をデータベース側で定義できる仕組みです。

このアプリでは、全テーブルに `org_id`（事業所ID）を持たせ、ログイン中のユーザーが所属している事業所IDと、データの `org_id` が一致する場合だけ、そのデータを扱えるようにしています。

`USING` は、すでにあるデータを読む・更新する・削除するときの条件です。`WITH CHECK` は、新しくデータを追加したり、更新したりするときの条件です。

この2つを設定することで、

という制約をかけています。

ここで重要なのは、事業所IDの判断をブラウザ側に任せていないことです。

たとえば、悪意のある人がブラウザから「自分の事業所IDは別の事業所です」とリクエストしても、それは採用されません。

`my_org_id()` が、ログイン中のユーザーIDをもとに、データベース側で所属事業所を確認します。

つまり、RLSは「画面で隠す」ための仕組みではありません。

データベースそのものに、

この人には、この事業所のデータしか渡さない

というルールを持たせる仕組みです。

SupabaseのようにREST APIでデータベースを扱う場合、このRLSを患者情報、薬剤情報、記録、スタッフ情報など、事業所ごとに分離すべき【すべて】のテーブルに確実に設定しておくことが重要になります。

私の設計書をSEの方に見ていただいた際に、ここを特に丁寧に設計しろと言われました。

今すぐ登録する

③-2. 管理者だけが削除できる

スタッフには `admin`（管理者）と `staff`（一般）の2種類があります。削除操作は管理者のみ許可しています。これをロール管理と呼びます。

ブラウザ側でロールを書き換えても、データベース側の関数が実際のスタッフ情報を参照して判定します。「私は管理者です」と主張しても無効です。

④ 操作ログ——誰が何をしたか

医療現場では「誰がいつ何を変更したか」を追跡できることが重要です。

このアプリには `audit_logs` テーブルがあり、ログイン・薬の追加・残数の変更・削除などをすべて記録します。

ただ、ログを記録するだけでは不十分です。もし誰でもログを書き込めるなら、「誰が書いたか」を偽装できてしまいます。

このアプリでは、ログの書き込みをデータベース側の関数だけに限定しています。

さらに、`audit_logs` テーブルへの直接書き込み権限をデータベースレベルで剥奪しています。

ブラウザから「田中さんが操作した」と偽ってログを書き込もうとしても、物理的にできません。ログを書けるのはデータベースの関数だけです。

⑤ 通信・ヘッダー——ブラウザ経由の攻撃を防ぐ

画面を開いているだけで攻撃される可能性がある、というのがWebの現実です。

外部の悪意あるスクリプトを読み込まれたり、偽サイトに埋め込まれたりする攻撃に対して、セキュリティヘッダーで防衛しています。

サーバーからブラウザにヘッダーを渡すことで、制御を決めることができるのです。

5. 全体を図にすると

どこか一つが突破されても、次の層が守ります。

6. 既知の課題も正直に書く

完璧なシステムはありません。このアプリにも残っている課題があります。

認証トークンの保存場所

ログイン後の証明書（JWT）はブラウザのローカルストレージに保存されます（Supabase のデフォルト動作）。スクリプト攻撃でページに悪意あるコードを注入されると、証明書を盗まれる可能性があります。

セキュリティヘッダーで外部スクリプトの読み込みを制限することで軽減していますが、根本的な解決には別の実装が必要です。現在の対応水準で運用上のリスクは低いと判断していますが、今後の改善点として把握しています。

操作者名はログイン時の入力値

薬の残数を誰が更新したかを記録する項目は、ログイン画面で入力した名前がそのまま使われます。監査ログはデータベース側で本人確認していますが、各テーブルの「更新者」はクライアント側の入力値です。今後、スタッフ情報と統一していく予定の部分です。

7. 医療管理者として「何を確認すべきか」

ITツールを職場に導入するとき、「セキュリティは大丈夫ですか？」と聞くだけでは評価できません。

具体的に聞けることを整理しておきます。

データについて

- このシステムはどんな情報を保存しますか？（個人情報の範囲確認）
- 退職者のアカウントは、いつ・どうやって無効化できますか？
- 他の事業所や組織のデータと混在しませんか？

アクセス管理について

- スタッフごとに権限（見られる範囲）を変えられますか？
- ログイン方法に多要素認証（MFA）は使えますか？
- 誰がいつ何を操作したか、ログは残りますか？

運用について

- ログは改ざんできない仕組みになっていますか？
- データのバックアップはどのくらいの頻度で取られていますか？
- 万が一問題が起きたとき、誰に何をどう連絡すればいいですか？

「クラウドですか？オンプレですか？」より、これらの質問の方が実態に近い評価ができます。

今すぐ登録する

8. 法令・ガイドライン

医療情報を扱うシステムには、法令上の義務があります。

個人情報保護法（改正 2022年）

- 個人情報を取得するときは利用目的を明示する義務がある

- 漏洩が発生した場合、72時間以内に個人情報保護委員会へ報告する義務がある（2022年改正で義務化）

- 影響を受けた本人への通知も必要

要配慮個人情報

病名・診断名・投薬歴・処方情報は「要配慮個人情報」に該当します。通常の個人情報より厳格な取り扱いが必要で、取得には本人の同意が原則必要です。

薬の名前を記録するシステムは、このカテゴリに触れる可能性があります。導入前に確認が必要な点です。

厚生労働省「医療情報システムの安全管理に関するガイドライン」

第6版（2023年）が最新です。電子保存の3原則を定めています。

9. まとめ——「運用でやりたいこと」を設計の言葉に変える

医療現場でのツール導入を進める中で、最も変わったのは要求の言語化です。

以前は「セキュリティが心配なので」で止まっていた会話が、今はこう言えるようになりました。

「退職したスタッフは即座にアクセス遮断したい。だから、アカウント管理は一元化して、無効化を1操作で完結できる設計にしてください」

「他の事業所のデータを誰も見られないようにしたい。だから、データベース側で組織ごとに分離してください」

「誰が残薬数を更新したか後で確認したい。だから、すべての更新操作をログに記録し、改ざんできない設計にしてください」

セキュリティは、クラウドかオンプレかで決まるものではありません。

誰が・どの権限で・どの情報に・どうアクセスできるかを設計すること。

そして「こういう運用をしたいから、設計はこうしてください」と言えるようになること。

それが、医療現場でのテクノロジー活用の第一歩だと思っています。

---

このアプリは現在試験運用中です。導入検討・フィードバックは X: @nurselog_ まで。

薬剤管理アプリLP

#看護師 #訪問看護 #医療DX #セキュリティ #個人開発 #ClaudeCode #Supabase #ICT活用 #在宅医療 #訪問看護師 #医療情報 #個人情報保護

訪問看護師用の残薬アプリを作ったとき、そして病院の外来問診自動化アプリの開発に関わらせていただきたとき、同じ違和感を持ちました。

同期とこれは楽になるぞと思って作った残薬アプリの仕様書を、管理者に提示し、使用許可待ちをしていました。

「個人情報の話もあるからさ。個人開発者だからさ。」という返答が返ってきた。

「個人情報が漏洩しないようなセキュリティでないといけない」そんな漠然とした問題意識はあれど、どんな設計(運用と技術)になっていればそれがクリアしているのかわからないーーそのような状態なのだろう。

このとき、強く感じました。

あたり前ですが、看護師は看護のプロです。

今までは管理者でもそんなことを理解している必要なんてありませんでした。
その想いをSubstackに投稿した所、こんな反応がありました。

「わかります。往年の世代が変わらないんですよね。」

ーーそれは、私が問いたいことではありませんでした。

年齢や世代の問題として語りたいのではないし、管理者を責めたいわけでもない。ただ、現代の医療管理に必要な判断材料がすでに変わってしまったという話をしたかった。

そして、その変化に誰も追いつけるような仕組みがないまま、医療DXだけが進もうとしていることへの危機感をちゃんと言葉にしたかったのです。

だから、書きます。

1. はじめに

医療機関の管理者の多くは、地頭がよく臨機応変に現場判断ができる方々です。

自分で直接管理ができない所まで確認し、急な欠勤による勤務配置変更、利用者さんの状態変化、困難な家族対応、医師・病院との調整、スタッフの感情、制度変更のキャッチアップなどなど..

そういう複雑なものを日々判断しながら現場を動かしています。
私は、そのことをとても尊いと思っています。

だからこそ、これを読んでくださっている管理者の方に最初にお伝えしたいのは、これは能力批判の記事ではないということです。

問題は、管理者個人の能力ではない。

繰り返しますが、時代の「医療管理」に必要な判断材料が、すでに変わってしまったということ。

今の医療管理には、看護力、調整力、洞察力に加えて、ITリテラシーが必須になっている。

だから私は、構造ごと問い直したいと思っています。

2. 医療IT化の歴史:紙を電子にする時代から始まった

まず、医療DXの話をする前に、医療のIT化がどこから始まったのかを少し整理したいと思います。どのような流れで「今」につながっているかわかってもらうためです。

日本の医療IT化は、2001年の「保険医療情報システム検討会」から本格化しました。2002年度からの約5年間を対象にした「保健医療分野の情報化に向けてのブランドデザイン」では、電子カルテやレセプト電算処理システムの普及目標が掲げられていました。

この第一段階の目的は、シンプルでした。

紙をなくす。
計算を速くする。
記録を保存しやすくする。

これはとても大切な進歩です。でも、これではまだDXではありません。これはデジタイゼーションです。紙をデジタルに置き換えただけで、業務そのものは変わってない。

次に、医事会計・オーダリング・電子カルテが連携するようになり、「業務の流れをシステムで繋ぐ」段階に入りました。それでもこの段階も、もともとある業務をそのまま電子化することが中心でした。

そして現在、医療記録はただ保存するだけでなく、DPCデータ(国に提出するいろんな診療情報)として分析され、病院間のベンチマーク(比較分析)に使われ、診療報酬の決定にも影響を与えるようになってきました。

ここで一つ重要なことがあります。

看護記録も、同じ道を辿りつつある。ということです。

医療情報システム開発センター(MEDIS-DC)が管理する「看護実践用語標準マスター」には、看護行為が約3,000語・看護観察が約6,000語が体系化されており、2016年には厚生労働省標準規格に認定されています。2022年には「JAHIS看護データセット適用ガイド」として、これらのマスターを用いた実施履歴を蓄積する仕組みがJAHISによって公表され、IoTや医療連携のための技術的なDX基盤が誕生しました。

訪問看護においても、2022年に「訪問看護計画等標準仕様」が整備されました。訪問看護計画書・報告書・記録書などを電子的に連携するための標準フォーマットです。

看護の言語が、少しずつデータ構造に乗り始めています。

これは何を意味するでしょうか。

看護の専門性は、これまで「経験と直感」として語られてきました。でも実際には、観察し、判断し、記録し、改善するという情報処理のプロセスが看護の核にあります。

私個人としては、ここもDX化を妨げる要因になってるのかなといった感覚があります。

「看護が言語化される」はいいけど、「看護がデータ化されて活用される」と聞くと、なんか冷たくて看護じゃないと感じます笑。
ものは合理的なのに現場に届かない理由の一つでもあるかなと思います。

ただ、最近では、稀有な例として、名古屋大学との共同研究で、訪問看護の臨床判断の再現性を保つツールの作成・販売なども行われるようになりました。

訪問看護の現場で、看護が体系化されて活用しやすいような形で現場にある、素晴らしいことだと思います。

3. 国はすでに標準化へ向かっている

一方で、国の方針はかなり明確です。

2022年に政府は医療DX推進本部を設置し、2023年の6月に「医療DXの推進に関する工程表」を決定しました。3本柱はこれです。

1. 全国医療情報プラットフォームの創設

2. 電子カルテ情報の標準化

3. 診療報酬改定DX

2030年までに希望する病院がクラウド型のシステムを導入できる環境を整備する方針が示されています。医科診療所向けの標準型電子カルテは2026年度中の完成を目指して開発が進んでいます。

要件として挙げられているのは、電子カルテ情報共有サービスへの対応、SaaS型クラウド、標準API、データ引き継ぎ可能な互換性ーーといった概念です。

つまり、

標準化、クラウド、API、データ連携

医療情報を「閉じたシステム」から「つながる仕組み」へ変えようとしている。この流れは、人口動態と社会保障費の観点からも止まらず進んでいってほしい。

では、現場では何が起きているのか。やっと、本題に入っていきます。

4. でも現場では何が起きているのか

IPA(情報処理推進機構)のDX白書2023によれば、医療・福祉は他産業と比べてもDXの取り組みの割合が低い産業群として分類されています。一部では医療・福祉業界のDX取り組み割合がおよそ9%とも紹介されています。

国の方針は進んでいる。でも、現場実装は、まだ始まったばかりです。

その実態は、、、

病院看護師：現場も人手が足りず、業務量の多さからか風土がピリついている。人間関係が悪すぎるってわけではないけど、耐えられない子からやめていく、、。まずは、業務効率化できる所からやろう。IT補助金があるから、看護記録を自動化するツールを入れるのはどうか。

上層部：看護師は直接利益を上げる部署ではないから、「費用対効果が見込めないんじゃない？」

看：残業代と採用の経費が下がり間接的に利益を出せます。

上：「そんなにいうならじゃあ、入れてもいいよ。」

看：業者が来てツールの仕様を説明してくれた。でも、「これはできます」にも齟齬が多い。あれ、思ったより自動ではないんだな。どう動いてるかわからないから、なんか十分に理解ができないな、、。でも、まあ、まず、電子カルテと連携したい。あ、別会社？？そうですよね。

電子カルテのベンダーさんに連絡をとり改修費の見積もりを依頼する。

電：新しいツールとの連携？うちのシステムとどう連携するんだ？え、UI画面にボタンを設置するだけ？そうといってもリスク換算しないと、、外部のツールの仕様がわからないもんな。いつも通り見積もり出すか。「これくらいの見積もりになります。」

「数十万から100万」

看：「え？！」

業者：「え？？！」

電：「え？！(他のベンダーどれくらいで見積もってんの？！)」

ちゃんちゃん。

こういうことが、医療現場では日常的に起きています。
(もちろん社内SE様が素晴らしすぎて、改修費も設置費も安くスムーズにいく所もあります。)

5. 問題は「ベンダーが悪い」ではない

立場を利用して法外な改修費を請求するベンダーが悪だ！と以前の私はそう思ってました。医療機関は国のお金で成り立っている部分も多い。取れるだけ取ろうと足元見られているだ！と憤ってました。

ただ、ここで大切なのは、これはベンダーだけが悪いという話ではないということです。

ベンダーも、外部ツールとの仕様の相性を今、完全には把握できない。だから、安全策として工数を大きく見積もる。これは合理的な判断です。

本当の問題は、医療機関側に仕様を読める人がいないということです。

業務をデータの流れとして説明できる人がいない。
どこで個人情報漏洩のリスクがあるのか、使用している技術が適切か、運用設計が適切かを理解している人がいない。

見積もりに対して、どこが必要でどこが過剰かを判断できる人がいない。
ベンダーと対等に話せる医療者・社内SEがいない。

その結果、医療DXが「現場のための変革」ではなく。外注費を払って耐えるイベントになってしまっている。

敵はベンダーではありません。

仕様を読めないまま意思決定しなければならない、医療組織の構造そのものです。

今すぐ登録する

6. 看護師とSEの文化の違い

ここで少し視点を変えて、看護師とSEの文化について考えたいと思います。
一見全く違う職業に見えますが、実は共通点があります。

どちらも生涯学習のお仕事です。

看護師・医療者は、日々変わるエビデンスに適応して、患者さんや利用者さんに適切な看護、医療を提供します。
SEさんも同じです。特にこちらの方が、変化が激しい。常に、言語・フレームワーク・クラウド・セキュリティ・API・設計思想が変わり続ける。SEさんはこのキャッチアップも技術の一つかもしれません。

どちらも変化する現場の中で学び続けるお仕事です。

でも、根本的に違う点が１つあります。

看護師はITに「100点の正解」があると思いがちです。

看護では、人によって看護力が違うことを知っています。同じ患者さんを見ても、新人とベテランで拾える情報が違う。同じ声かけでも、相手の反応が変わる。看護には熟練や技術選定があることを、看護師はよく知っています。

でもITになると、急にこう思ってしまう。

システムには絶対的な正解がある。
導入すればうまくいく。
セキュリティは100%守られるはず。

ITで全てが見通せている人はいません。昨日の正解が古いものになっている。そんなことはよくある世界です。

また、ITはどちらに転んでも手段であるため、最小限で作って適応させる作り方がスタンダードです。

そして、どれだけプロのSEさんがプログラミングのレビューを行ってもそこに「人間」が介在してる以上動いた時の抜けはあるものです。

この感覚を持てるかどうかが、医療現場のIT導入を大きく左右します。

7. 管理者に必要なITリテラシーとは何か

今までの流れで、医療DX推進は進んでいるが、医療機関側に仕様を読める人がいない、ITに対しての漠然とした不安感があることをお伝えしてきました。

その中で管理者が何を理解すれば、安全にかつ時代に即して効率化が進むか。
どんなITリテラシーが求められているかをお伝えします。

「プログラミングができること、パソコンが得意であること」、違います。

現代の医療管理者に必要なITリテラシーは、

• 業務フローを描けること
  業務の流れを言語化し、「誰が」「何を」「いつ」「どんな情報をもとに」動いているかを整理できること。

• データの流れを理解できること
  どこで情報が生まれ、どこで加工され、どこで使われるのかを把握できること。

• 見積もりの妥当性を質問できること
  「なぜこの工数がかかるのか」「代替手段はないか」を問える状態でいること。

• セキュリティを現実的に判断できること
  「完全に安全な方法」など存在しないことを知った上て、リスクとコストを天秤にかけられること。

• 小さな自動化の可能性を見抜けること
  「この作業、毎日繰り返している」「この入力、二重になってる」を発見し、改善の余地を感じられること。

これはプログラムを書く力ではありません。

業務をITを活用して業務を設計する力です。
概要をわかっていれば、あとはわかっている人に質問し、具体を理解していくだけです。

8.セキュリティ幻想を壊す

ここで、皆さんが不安であろう、セキュリティについて触れていきます。一体全体、何がクリアできてれば、セキュリティが保たれて安心と思えるのよ、と。

従来から、医療データのセキュリティについて、現場には根強い思い込みがあります。

「オンプレ(院内サーバー)なら安全、クラウドは危険」

これは、もう通用しない認識です。

厚労省の「医療情報システムの安全管理ガイドライン第6.0版」でも、電子カルテには保存性・真正性・見読性という要件が求められています。そして国の医療DXは、クラウド型SaaSへの移行を推進しています。

セキュリティは「場所」ではなく「設計と運用」です。

重要なのはこれです。

• 誰が、どの端末から、どの権限で、どの情報にアクセスできるか

• 操作ログは記録されているか

• 退職者のアカウントは適切に削除されているか

• 2段階認証派設定されているか

• バックアップ体制はあるか

• 端末紛失時に止められるか

• インシデント発生時の対応手順はあるか

この感覚を管理者が持てるかどうかが、これから問われると思っていますし、これが満たされているならば、不必要に不安になることはありません。

これは、わかってはいるけど、不安なのという方は、具体的な技術スタックと実際のプログラム設計などは、その都度、具体を確認すれば良いです。

運用と設計でクリアしたい具体のセキュリティリスク項目はこちらを参照ください。
こんな用語があるらしいと思ってもらえたら大丈夫です。

小さいアプリに対する個人情報保護と運用設計の実際

上記は私の作ってる残薬アプリのいちLPです。個人情報保護(約束)とセキュリティ(技術)の違いも理解できると思います。

私自身ももっと深い理解や技術選定実装へ落とし込んでいきたいと思います。

9. 解決策：医療者で構成されたDX専門部署を作る

変化に誰も追いつけるような仕組みがないまま、医療DXだけが進もうとしていることへの危機感があると冒頭でお話させていただきました。

私が提案したい答えの一つは、医療者で構成されたDX専門部署を作ることです。

ただし、「情報システム部門」ではありません。
私が提案したいのは「臨床翻訳部門」という概念です。

現場の困りごとを聞く。業務フローに分解する。データの流れに変換する。小さなツールを作る。業者に依頼すべき部分と内製すべき部分を分ける。見積もりや仕様を評価する。SEさんと現場の立場から現実的な話をする。現場教育をする。

看護の判断を、データと業務設計に翻訳できる人たちの集まりです。

医療者は勤勉な方が多いので、作ればそういう人は出てきます。すでに、個人で取り組んでいる人も多いです。

10. 結論：医療DXの主語を、現場に戻す

医療DXとは、システムを導入することではありません。

現場が、自分たちの業務を再設計することです。

合理性を追求しないケアが人には必要であり、その時間を捻出したい。

よって合理性で説明できる範囲のことは、一つでも多く手放したい。

ーー東京医療保険大学の瀬戸僚馬教授は、看護DXの目的をこう語りました。

看護師がIT・AIを学ぶことは、看護から離れることではありません。むしろ、看護を守るために必要なことです。

看護管理者のあなたが、一スタッフの私が、現場をよくするために必要なことは、

もう一度現場に医療DXの主語を戻す取り組みであると考えています。

どうか、看護師の皆様が本質的で、温かみのある看護が提供できる場が整いますように。

押し付けがましい内容もありましたが、ここまで読んでいただきありがとうございました。たくさんの管理者の方に届いて欲しいです。

私自身は、現在京都で訪問看護師として働きながら、残薬管理アプリなど個人開発を行っています。ずっと、東京で働いていたので、東京も好きです。

現場の困りごとが一番わかっている当事者が、自分で設計することで、多くの看護師さんの仕事がめちゃ楽になるように頑張っています。

自分で作ってみることにも興味がある方も多いと思うので、ITハンズオンとか、何か作ってみる講演会とかやってみたいなと思っています。

とにかく、頑張ってる看護師がのびのびと生きれますように。

Substackもご登録いただけますと、嬉しいです！こちらのボタンで登録できます〜

今すぐ登録する

参考文献

[1] IPA DX白書2023（独立行政法人情報処理推進機構）

[2] 厚生労働省「医療DXの推進に関する工程表」（令和5年6月）

[3] 「医療DX令和ビジョン2030」厚生労働省推進チーム

[4] 医療情報システムの安全管理ガイドライン第6.0版（厚生労働省）

[5] 看護実践用語標準マスター（MEDIS-DC, 厚生労働省標準規格, 2016年認定）

[6] JAHIS看護データセット適用ガイド（JAHIS, 2022年）

[7] 訪問看護計画等標準仕様（厚生労働省, 2022年）

[8] 島岡理恵ら「看護業務量の実態調査 — 7対1看護体制の業務の見直しに向けて」奈良県立医学部附属病院看護研究発表集録, 2015

[9] 瀬戸僚馬「医療・看護のDXに向けた標準化の取り組み」JAHIS標準化推進部会 業務報告会 特別講演, 2024年3月

[10] 村上玄樹「医療・看護現場におけるICTの普及に伴う情報リテラシーの重要性」令和5年度第45回看護師卒後研修会, 産業医科大学病院