クラウド電子カルテを支えるテクノロジーの光と闇

Transcript

1. クラウド電子カルテを 支えるテクノロジーの 光と闇 @jooohn1234

2. M3, Inc. @jooohn1234 • 電子カルテチームリーダー • Scala / FP 好き

   • 育休エヴァンジェリスト (社内)
3. None
4. None
5. None
6. None

7. 電子カルテ

8. 受付 診察 会計

9. 受付 診察 会計 電子カルテ 患者への医療行為を記録

10. 受付 診察 会計 レセコン 会計計算・保険請求

11. None

12. 今日はなすこと

13. 電子カルテを支える イケてるモダンな 光のテクノロジー

14. 電子カルテを支えるために こうするしかなかった 闇のテクノロジー

15. 光 と 闇 のテクノロジー • クラウド • レセコン

16. クラウド電子カルテ

17. クラウドなんていまさら 当たり前では・・・

18. ？ ？

19. ？

20. None

21. 電カル導入の 5％未満 ※と言われている

22. 光 当たり前すぎて見えなかったクラウドの良さ • 更新が容易・迅速 • どこからでもアクセス可(訪問診療) • Multi AZによる対災害性 •

    BaaS, PaaS, SaaSの利用 • 集中管理によるコストメリット • etc
23. None

24. ただし

25. 良いことばかり ではない

26. クラウド電子カルテ

27. クラウド電子カルテ 院内ネットワーク PACS レセコン 院内機器

28. クラウド電子カルテ 院内ネットワーク PACS レセコン 院内機器 ？

29. うーん・・・

30. つらい

31. クラウド電子カルテ 院内ネットワーク PACS レセコン 院内機器 双方向通信

32. 闇 院内ネットワークで起動するエージェント • 保守のハードルが高い ◦ アプリアップデートの問題 ◦ 調査の問題 • JREの継続的アップデートが必要...

    (誰が やるの) ◦ Electronへの移行を検討中 • 過渡期感ある

33. クラウドまとめ • クラウド最高 • 全部クラウドにできなくて辛い • はやく全部クラウドの世界になってほしい

34. レセコン

35. 受付 診察 会計 レセコン 会計計算・保険請求

36. 闇 避けては通れないレセコン機能 • カルテの情報をレセコンと同期する機能 はほぼ必須 • 診療報酬点数計算・保険請求 ◦ 複雑な処理の塊で、開発ハードルが高 い

37. 闇 避けては通れないレセコン機能 概要 UX 開発コスト 連携型 サードパーティのレ セコンと連携 悪 中

    一体型 自社開発の レセコン 良 激高

38. 闇 避けては通れないレセコン機能 • 2015年 ◦ 連携型としてローンチ ◦ レセコン機能の先行調査開始 • 2017年

    ◦ 一体型・レセコン単体機能リリー ス

39. 複雑な処理に 立ち向かう

40. 光 複雑な業務知識に立ち向かう • Scala ◦ 管理しやすく(OOP)、堅牢 (FP) • Functional Programming

    ◦ テスト・再利用が容易 ◦ 点数計算は巨大な関数 • Clean Architecture ...のエッセンスを拝借 ◦ 複雑な計算ルールを作用と分離

41. https://8thlight.com/blog/uncle-bob/2012/08/13/t he-clean-architecture.html

42. 光 Entities • コアになるビジネスルールを表現 ◦ 会計計算・保険請求用の集計処理 • [FP] 純粋なコンポーネントのみで構成 ◦

    定数・不変オブジェクトのみ利用 ◦ IO, Future, Exceptionといった作用無し ◦ テスト・再利用・理解しやすい ▪ ここを一番厚くテストしたい
43. None

44. 副作用のない純粋な関数 この層で起こるエラーはビジネスルール。 値としてモデリング。

45. 光 Use Cases • 永続化など含むアプリケーション要件 ◦ DBIO, Future が出てくるのはこの層 •

    [Scala] for 式による作用の直列処理 ◦ 作用を起こす場所を一箇所に • [Scala] Tagless Final による作用の抽象化 ◦ ...をできたら良いなと思っている ◦ この層もよりtestableに
46. None

47. 作用の型を宣言。Scalaはここを抽象化すること も可能！(高カインド型パラメータ)

48. 作用を起こす処理。この層ではInterfaceに依存 するようにし、DIするようにするとテストしやすい。 (Dependency Inversion Principle)

49. for式を用いて、作用の処理を一箇所にまとめ る。ハッピーなケースについてのみ記述

50. Entities層を利用

51. 光 sbt multi project builds • 依存関係を明記 ◦ UseCases層はEntities層 に依存

    ◦ Entities層はDBアクセスライブラリに非 依存 • 依存関係のないコードを読めなくなる。

52. PACS レセコン 院内機器

53. PACS レセコン 院内機器 連携型の世界

54. PACS レセコン 院内機器 一体型の世界

55. クラウド最高！

56. まとめ • レガシー業界では遺産に向き合う必要が ある ◦ 「すべてがモダン」にはならない過渡期 がある • モダンなテクノロジーや設計手法を武器 に少しずつ良くしていっています