Kengo's blog

Technical articles about original projects, JVM, Static Analysis and TypeScript.

元toB系プログラマが医療情報技師の勉強をして面白かった部分

今年の医療情報技師能力検定試験に向けて、医学医療編・医療情報システム編の学習を進めてきました。toB系プログラマとして働き始めてから見てこなかった単語や発想がたくさんあって面白かったので、印象的だったところをまとめます。

医療現場はロールベースかつイベントドリブン

医療現場では(乱暴に言うと)各部門やシステムの間を「オーダ」をはじめとしたメッセージが飛び交っている、というモデル化ができそうです。 多くの役職だと何ができるかが法で定められていて、そうした役割をどう組み合わせるかも予め想定されており、そのコラボレーションをメッセージで行っているということです。

これはけっこう医療現場というものを特徴づけるものだと思っていて、パッと思いつくところでも以下のような事が考えられます:

  • 業務の属人性を下げるための仕組みとして機能することが期待される。
    • アクターのTODOや期待されるアウトプットが明確。特に医療行為や看護行為は国際的なマスタがあり、世界的に定義が明確っぽい。
    • アクターの専門性に対する期待も明確なので、教育や評価も(簡単とは言わないけど)比較的やれそう。
  • アクターのロールやコミュニケーション方法が全医療機関共通なので、転職も比較的しやすそう。
    • プログラマだと言語や利用してるクラウドが同じでも現場の働き方はぜんぜん違うけど、医療現場だと少なくとも部署間コミュニケーションは似ていると期待できそう。
    • 紙カルテ&電子カルテみたいな、採用している仕組みが違うと細かいやり方は大きく違ってくるとは思うけど。
  • アクター=部署あるいは資格持ちの人間なので、病院というシステムを動かすための最低限の人数が多くなる。
    • コーダー兼デザイナー兼テスター兼広報です!みたいなことが法的にやりにくい。医師ひとりの診療所で在宅医療やるぞみたいな例はあるみたいだけど……。
    • 情報の交通整理や決断が困難かつボトルネックになる可能性が高い。実際医師や看護師の長時間労働などが問題になっている。

Team Topologiesに親しんでるとStream-aligned Teamに権限を移譲していかにスムーズに動かすかという発想になるんですけど、病院というシステムだとそもそもどこがStreamなんだっけとか、各種検査というComplicated Subsystemをどう動かすべきなんだろうとか、普段使ってない頭の部分を使っている感じがしていいですね。

科学的知見を幅広く活用するための「ガイドライン」

コロナ禍を通じて私にもランダム化比較試験が強いらしいみたいな雑な理解はあったのですが、医療情報技師の学習をきっかけにEvidence-Based Medicine(EBM)という考え方があってランダム化比較試験よりも強いやつがあるということを知りました。システマティックレビューやメタアナリシスがそれです。強い研究を統合してもっと強くするみたいな雑な理解でいますが、人間の叡智を集結して現在のベストを導き出すというのはなんか知性の総力戦という感じでいいですね。

さて医療の世界には診療ガイドラインというものがあり、医療機関ごとの医療の質を底上げしたり医療資源を効率的に扱ったり提供された医療の評価に使ったりしています。日本では医師会や厚生労働省から出ているものが多数あるようです。国立研究開発法人国立がん研究センターがシステマティックレビューやメタアナリシスも含めた説明をしているのでおすすめです:

ganjoho.jp

医療が研究の山の上に成り立っていることはなんとなく知っていたつもりでも、医療関係者がどう知識をアップデートしているかとかはイメージがなかったため、なるほどこうやって国として知識を共有し医療の質を保っているのだと感心しました。

ちなみに医療機関向け情報セキュリティの世界でも3省2ガイドラインというものが提供されています。医療情報技師なら内容を把握していることが求められますし、医療業界向けのサービス提供をする場合も必ずこれを読むことになります。これは診療ガイドラインではないのでメタアナリシスとかは関係ないかもしれないですが、少なくともIT業界標準の考えは多く盛り込まれているように感じます:

www.mhlw.go.jp

www.meti.go.jp

医師の相互監視に課題がありそう

転職する前に医療業界に抱いていたイメージとしては、インシデント対応ができてなさそうというのがありました。いや、個人的体験としては特に不満を感じることもなかったですし、インシデントにぶち当たったこともたぶん無いのですが、「失敗の科学」の印象が強かったのです。この本は「航空業界にあって、医療業界にないもの」とデカデカと書いてあるレベルで(アメリカの)医療業界にダメ出ししています。

失敗の科学

失敗の科学

Amazon

ところで医療情報技師の学習範囲にはインシデントの扱いや医療安全や医療過誤、原因分析や再発防止などが含まれています。RCA(Root Cause Analysis)やProblem SolvingあたりはtoBプログラマなら扱ったことあることも多いと思うのですが、これに加えて4M5E分析とかSHELモデルとかも扱っていて自分は初見だったので勉強になりました。また国内の事例や記事なんかを追いかけても真摯に課題に向かっている方が多く、結構やれてるじゃんという感想になった、んですが、残念ながらこの事件が起こってやっぱダメなところはダメなんだなという現実を思い知ったところがあります:

www3.nhk.or.jp

少なくとも医師同士の相互監視は、セカンド・オピニオン(厳密には監視ではない)やカウンターサインを除けばあまりなさそうだなというのが今の自分の認識です。もちろん日頃から院内で情報交換(カンファレンス)を行っていたり、インシデントレポートが提出されれば然るべき検討が行われたりするはずですが、少なくとも前述の事例ではカルテを読み合うようなことはやっていなかったのでしょう。

医師が長時間労働していることを踏まえるとここはシステムが余力を創出することで貢献できる部分かもしれないなとは思いますし、カルテ記載事項の質の判断とかは機械学習でなんとかできそうな気もします。

病院の壁を超えたPDCAサイクルが回せるように情報が公開されている

診療ガイドラインの実施率であるとか、病床機能の割合であるとか、様々な各病院から提出されたデータが統計されたうえで公開されています。例えばこのへんとかです:

hospia.jp www.mhlw.go.jp

これ普通の企業の活動だとちょっと考えにくいというか。強いて言えば離職率とか初任給とかは他と比較して改善の参考にはすると思うのですが、じゃぁ他社製品の単体テストカバレッジとか変更のリードタイムとかMTTRとかはそもそも公開されていないので参照できない事が多いと思うのですよね。ところが医療機関の場合は医療サービスというコア機能のデータが世に出ているわけで、いやこれすごいなって思います。もちろん病院側だけじゃなくて、ガイドラインとか政策とかの側でも参考にしているのでしょう。

ちなみに海外だと病院ごとだけじゃなくて医師ごとのデータとかも見られるらしいです。すごい。

まとめ

元toB系プログラマが医療情報技師の勉強をして面白かった部分として、医療現場がロールベースかつイベントドリブンっぽいなぁということと、診療ガイドラインやデータに基づく改善が回る仕組みがあってすごいなということを書きました。またインシデントを隠さず業界全体として次に活かすための体制や仕組みはありそうなので、あとは実行の浸透が重要=やっぱり医療DX大事だなぁと改めて感じました。

医療情報技師の資格試験は医学・医療編がちょっと重いものの、医療システムのおおまかな構造や他施設との連携などについても学べるので、私みたいに医療業界の外から来たプログラマは齧って損はないと思いました。おすすめです。

2023年10月5日 追記

合格しました。

twitter.com