こんにちは！
とある急性期病院で理学療法士として勤務していますDrrrrといいます．
いままでやってきた仕事や趣味もろもろを備忘録がてらまとめようと思います．
メジャーな話題はよそにおまかせして，需要があるかよくわからないニッチな話題をかければ良いかな，というモチベーションです．お願いします！
注意
医療従事者の方にも読んでいただきたいので，IT系の専門用語はわかりやすく（ときには少し曖昧に）書いています．もし明らかに間違っている，などご指摘することがございましたら，優しく指摘していただけると助かります．
病院の経営と対策
病院経営はどこでもかなりシビアな時代になりました．
ここでは詳細は省きますが，社会保障費の圧縮に加えて，人件費・物価関連の高騰が重くのしかかっている現状です．
当院も例外なく影響をうけており，人件費削減を目標とした業務改善が急務となっています．
医療現場における業務改善でとりわけ熱いのはDX化とタスクシフト・シェアでしょうか．
タスクシフト・シェアはどこかで取り上げたいなと考えていますので，またの機会に．
DX化は医療業界関係なく，熱いテーマですかね．
医療現場におけるDX化
医療現場でDX化を掲げようとするといくつかの問題があります．
そもそもDX化において前提なのは，
DX化に関わるコスト＜DX化によって得られる利益
これが前提です．「なんかカッコよさそうだから導入してみよう！」なんて上層部が言い出したらストライキしましょう．
DX導入したけど導入・運用コストで赤字化なんて目も当てられません．
ほとんどの大掛かりなDX化が新しくソフト・ハードウェアを導入し運用することがほとんどなのでまずはこの原則を考える必要があります．
医療現場という特殊な環境上，導入コストが高い
医療業界という深く狭い業界では，電子カルテシステムや医療機器を提供する業者は限られたものになります．使用用途も他業界に比べて特殊であるため，どうしても高額なものになりやすいのが現状です．
特に電子カルテシステムはオプションをつけていくと，金額が鰻登りになるため，最低レベルの機能だけつけて運用ということがよくあります（残念ながら当院もそうです）．
もちろんDX化をうまく推進している病院施設もあります．
従来の連絡手段として用いられていた院内PHSをスマートフォンに置き換えた例ですね．とても素晴らしい取り組みですし，なにか真似ることができないか見学してみたいなーなんて思ったりしてます．
ですがこれが日本全国の病院で導入できるかというとやはり難しい印象があります．
もし臨床業務にかかわる従業員へスマートフォンを1台ずつ配布するとして，その導入費用がかかります．
さらに，そのスマートフォンの更新費用（更新や故障など含め）を考えると安くない費用です．
DX化を検討したけど，そもそも経営体力がないので，大規模なDX化が難しいんですね．
もともと健全な経営状態である病院がこれからきたる人件費・物価高騰に備えて将来的に行える対策の一つが世間一般で呼ばれるDX化というものなのでしょう．
そんなことはわかってるんだよ！どうすればいい！？
とまあ，前置きは置いておいて，実際問題早急な経営改善が必要な病院施設で行えるDX化ってあるのかなっていうのが今回のテーマでした．
当院の課題
もともとひょんなことからRやPythonを使う機会が多々あった自分ですが，この問題に少しでも組織貢献できないかな，というのがはじまりです．
リハビリテーション関連の話題でいうとリハビリテーション・口腔・栄養連携加算という診療報酬加算（病院の利益を決める仕組みです）が2024年から発足しました．当院でも早期から開始しています．
リハビリテーション・口腔・栄養連携加算
ざっくり説明すると，急性期病棟（いわゆる医学的治療をメインに行う病棟のことです）において，理学療法士や管理栄養士を専従者として配属し，その病棟へ入院した患者すべてを対象に48時間以内に適切な評価・介入をしてね，というルールです．
疾患別リハビリテーション
従来は疾患別リハビリテーションという枠組みで，医師がリハビリテーションの処方をおこなった患者を対象に評価・介入することがほとんどでした．
これからは病棟を包括して管理しましょうという方針です．
入院した患者すべてに評価・介入を行い，書類業務を行う必要があります．なので，いかに加算をとりつつ，時間的制約のなかで効率的に入院してきた患者をみていくか，というのが業務効率化の上で考える必要がありました．
病棟のベッド数にもよりますが，そこそこのベッド数でそこそこの回転率（入退院の多さ）があると，入院患者の情報をいかに迅速に把握し，管理していくか，というのが課題になります．
病棟のベッド管理（よくベッドコントロールといいます）は基本的に病棟に所属する看護師が行います．外来や救急外来，他病院からの転院，他病棟からの転棟などいろんなルートでやってくる患者をどのベッドへ収容するか，昼夜問わず看護師が調整します（マジリスペクト）．ただし，その業務の複雑さゆえに，他職種（理学療法士や管理栄養士など）への情報伝達が遅れたりすることがほとんどでした（そもそも伝達できないときもあります）．
当院では電子カルテ上で入退院および転科・転棟をリスト化する機能は標準で搭載されていますが，pdfやcsvなどで出力することはできず，なぜか直接プリンタへ印刷されてしまう仕様でした（うまくいじれば電子ファイルへ出力できるのかもしれませんが，電子カルテアプリ上で印刷プロパティが出てしまうので現場レベルではうまくいきませんでした）．日付の指定も前日の夜勤帯〜当日の日勤帯でまとめて抽出することができず，日付単位での抽出のみ，など痒いところに手が届かない...もしベンダーさんに機能の修正・改善を依頼するとしたら，そこでまたコストがかかる，というわけで仕方なしにアナログチックにベッドマップを睨んで監視する作業がほとんどとなっておりました．
「いい感じにハッキングして業務に必要な情報をまとめて抜き出せねえかなあ〜」なんて，上司が嘆いていたことを覚えています（ハッキングって）．
病院にはいろんな職種の方々がいます
病院という患者さんの個人情報絶対守るマンという環境において，電子カルテの運用はたいてい情報システム課が管理・運営をおこなっています．当院にも常勤の情報システム課（情シス）の職員が在勤しています．（臨床従事者は残念ながらほとんど関わる機会がありません．職場長など運営側の人と関わることがほとんどです）
簡単にいうと電子カルテなど院内の電子環境（たとえベンダーさんの外注であっても）の管理・運用の専門職ということなので，もちろんDX化の導入においては欠かせない存在となります．しかし，上記でお話しした難しい事情でなかなか動けないという状況かつ情シスのマンパワー不足というのもあり，比較的大きい病院だとそれぞれの部署における業務改善に関わることが難しい場面が多々あります（そもそも現場の方々が情シスの方々にお願いするという発想にいたらないことが多い）．
臨床研究に手を出していた私は一度，情シスの方とお話しする機会があって，
データウェアハウス
というものを教えてもらいました．
電子カルテにおけるいわゆる構造化データ（診察記事，検査データなど．CTなどの画像データは非構造化データなので別サーバーで管理されることが多い）をデータウェアハウスと呼ばれる倉庫に一元管理されていることがほとんどです．（下図参照）
https://jpn.nec.com/medical_healthcare/solution/dwh/index.htmlより引用
本来であれば，データサーバへアクセスしデータを直接書き込んだりすることはいろんな意味で御法度なので，サーバーを非公開にする（院内の人間がアクセスできないようにする）のですが，参照系DWHを提供している場合があります．
参照系DWH
診療にあたり実働するサーバーではなく，実働サーバーからコピーして倉庫へ保管するものです．直接書き込むことは基本できないですが，読み取り（参照）することができます．
DWHへの接続方法は色々な方法があると思いますが，一番応用が効くのはコードでやりとりする方法です．DWH（やDB)におけるコードは基本的にSQLを使います（ここでは技術的な解説は最小限としますので，成書やwebを参照ください）．
参照系DWHから読み取りできるアプリケーションを内製さえしてしまえば，外注するよりもローコストで作成・運用できます．
（なるほど！）と感じた私は上記の課題に対して，いけそうと思いました．
すぐに，現場の課題（入退院の情報を迅速に把握する必要があるが，それを満たすツールがない）と解決策（DWHからデータ抽出すればそのツールができるかも！）を職場長に提示しました．非IT系の職場長はよくわからないので，情シスの偉い人に確認してみる，とアポを打診してくれました．その日のうちにアポは実現し，情シスの管理職の方へ，課題と解決策をプレゼン，セキュリティ上の懸念はあるので作成したツールは情シスにオブザーバーとしてチェックしていただくことをお願いしました．
無事に情シス管理職の承諾を得て，DWHのアクセス権およびツール作成の公認を得ました．ついでにDWHの仕様書もいただきました．
ツールを作成するにあたり，アプリケーションとしてはExcelをベースにVBAでSQLを使うという構想に至りました．
院内PCというセキュリティ制約のある環境下であること（オフィスソフトは院内PCに標準搭載），非IT系である現場職の方でも慣れているExcel，というのが主な理由です．
いただいたDWHの仕様書を参考にデータテーブルを見ながら，使えそうな情報を拾い，ダッシュボードツールの作成が始まりました．
実際の流れ〜大変だったところ，苦労したところ
いきなりですが大変・苦労したところを書かせてください．障壁を乗り越えてこそプロジェクトって完遂するものです．
ダッシュボードツールの作成にあたり，まずは要件定義からはじめようと考えました．
要件定義
最初にターゲットとしていたリハビリテーション職（理学療法士，作業療法士，言語聴覚療法士）の方々で，おもに病棟を管理する主任の方達へヒアリングを行いました．
実際にヒアリングをしてみると，まあ見事に「欲しいデータ」がみんな違う（病棟によって診療科が異なるのでまあ当たり前なんですけども）．
よくあるのが，「この指標を見たい！」と言われたけど，実際にはカルテに自由記載のデータしかなくて，DWHには存在しているけどそれをどう定量化すればよいか困ったケースでした．「それはデータがないから自動化はできない」と正直に伝えつつ，「代わりにこういう指標なら近似できる」と期待値を調整する作業が必須でした．
極めつけは，業務フローが職種間で共有されていなかったこと．特に病棟間でローカルルールが存在することが多かったです．誰がどのタイミングで入力しているか，実はみんなあまり把握していなかった．これはまさに“医療現場あるある”で，データ設計をする前に業務整理が必要でした．こればっかりは私個人では解決できないイシューなので，病棟間で統一されていないデータは優先順位を下げ，データみてたらこんな課題がありましたと上司へフィードバックしました（それがきっかけで改善された業務フローがあったりする）．
データテーブルが無法地帯化している
前置きしておきますが，これは開発側の事情もあると思います．
DWHに収納されているデータはカテゴリによっていくつかのテーブル（診療記事とかオーダーとか検査データとか）が存在します．テーブルには各変数（例えば患者ID，名前，性別とか）が収納されています．SQL上でテーブル名と変数名（よくカラム名と言ったりします）を指定すると該当する変数のデータを抽出することができますが，まったく使っていない空白のカラムがあったりします．こればっかりはデータを実際に見てみないとわからず，カラムを一つずつ確認してシラミ潰しに使えるデータか確認していく，という作業が一番時間がかかりました．また，業務フローの変更などで途中で使われなくなったカラムなどがあり，それを整理していくのが大変でした．
でも仕方ないのです．病院は国が提示する診療報酬改定についていくために，経営戦略を変更する必要があり（病棟の方針転換など），現場の医療従事者は効率化を行うために業務フローを都度変更する必要があり，，，使われなくなったカラムはまさにそれを反映しており，なんだかエモい気持ちになりました．
技術的なところ
技術的なところは特に苦労した，ネガティブなことはなかったです．強いて言うなら臨床業務の合間にコードを書いていたので，なかなか集中できる時間を確保できなかったところでしょうか．まあコードは汚いです...
SQLに触れるのは初めてではなかったですが，やっぱりコードを書くときは色々調べて勉強しました．
今の時代はすごいです．先駆者やプロフェッショナルたちがweb上にわかりやすくSQLを解説してくれます．生成AIも出てきましたし．
Excelベースで実装するのは初めてでとてもワクワクしました．このワクワク感がモチベになるんですよね．
コーディングの壁，アプリケーション・ツールの壁は昔に比べてだいぶ低くなったのではないでしょうか．
技術的なところで触れると，Excel-VBAからODBC経由でMySQL DBへ接続しています．
今回の取り組みでは，読み取りを中心に，SELECTやWHEREなどの基本構文から始まり，GROUP BYやHAVINGによる集計処理，CASE WHENによる柔軟な条件分岐，さらにJOINやサブクエリ，ウィンドウ関数を用いた複雑なデータ抽出まで幅広く経験しました．
現場での要件に合わせてSQLをExcel-VBAに組み込み，パラメータをセル入力から受け渡す形にすることで，非ITでも柔軟に扱えるダッシュボードを構築しました．
プロトタイプとして作成したダッシュボードは，患者ID・患者氏名など基本的情報，入院病名や適応されているクリティカルパス名などの臨床情報，入院（予定）時間などをリスト化しました（ダブルクリックでクリップボードに保存しカルテ参照を容易にできるように）．抽出する日付・時間も自由に変更できるようにし，過去の日付や前日の夜勤帯〜当日の日勤帯をまとめて抽出できるようにするなど痒いところに手が届くようにしました．この時点でスタッフの皆さんにはかなり感動されましたが，使っていくうちに要望が次々と噴出しました．
改良した現在では，入院にあたって必要な書類業務がカルテ上で立ち上がっているか，入力されているかなどのチェック機能，過去研究で用いたデータをもとに作成した入院日数予測モデル（Excel上ということもあり線型回帰が限界でした）から算出した予想入院日数の提示を一部病棟用に作成したり，色々な機能を実装できました．
これから
PoC（新しい取り組みを検証すること）のフェーズはこれからです．後出しになりますが，臨床において何かしらのプロジェクトで業務改善などを図る場合は，必ず検証可能なデザインにすること．これに尽きます．
再掲になりますが，DX化において大事なことは「DX化に関わるコスト＜DX化によって得られる利益」です．
どんなにローコストなプロジェクトであっても，効果検証によってそのプロジェクトの持続の有無を判断していくことになるので，とても大事な判断材料になります．
今回の取り組みについては，スタッフの残業時間をKPI（アウトカム）にしています．ダッシュボード導入前，導入後で残業時間がどのように変化するか，時系列分断デザインで検証していく予定です（データ蓄積中）．
Qiitaで公開できるかは怪しいですが，もしうまくまとめればどこか公的な場で公開してみたいなと考えています．
なにが言いたいか
臨床（に限らないですが）には色々な課題があります．それは臨床研究を使って解決していったり，今回のような内製化を図ることでコストの壁を超えていったり，その実現にはいくつかのハードルがあるだけで，課題の認識さえできればアプローチはできると思います．そこには，技術的なこと（コードとかIT系とか難しいこと）は大した障壁にはならない時代です．
この記事からなにか刺激を与えることができたら幸いです．
今回はここまで．またの機会に．