Zenn
🏥

ispecの事業を支える技術

に公開
1

はじめに

株式会社ispec CTOの山田です。先日、ispecでEMをやっている元バスケ部のshinyaと一緒にバスケをしたのですが、美しいハンドリングと華麗なシュートフェイントにより完全に叩きのめされました。ソフトウェア開発だけでなくバスケの技術力も高い頼もしいEMです。

さて、かくいう私ははるか昔にispecの技術選定に関する記事を書きましたが、あれから3年近く経ち、以下のような大きな変化がありました。

  • 医療ドメインへのフォーカス
  • AI/LLMを活用したプロダクト開発

3年が経過して事業の方向性も変わり、それにあわせて技術スタックも変わっているため、本記事では現在のispecの事業を支える技術について紹介します。

事業概要

株式会社ispecは、医療システムのあり方を変えることを目指して医療DXを推進する事業を展開しており、主に以下の2つのサービスを行なっています。

  1. クラウド型の医療システム開発支援
  2. AIを活用した医療機関DX支援

Image

1は足元の売上・利益を作るための事業で、コンサルティングや受託開発がメインです。1で作った利益を2のAIを活用した医療機関DXの方に投資をし、トップラインを伸ばすという事業の組み方をしています。

以下ではそれぞれの事業の中でどのような技術を使っているか、その意思決定の背景について紹介します。

なお、フロントエンドにフォーカスした技術選定については、ispecのフロントエンドのアーキテクトであるshogoのこちらの記事で紹介していますので、そちらも併せてご覧ください。

サービス1. クラウド型の医療システム開発支援

クラウド型の医療システム開発支援の事業では、病院・病院グループ様に直接システムを提供するパターンとベンダー様の開発を支援する2つパターンがあります。

病院・病院グループ様向けの業務システム開発

病院の業務システムはすでに市場に様々なものがありますが、大きな病院様や病院グループ様の中には既存システムではカバーし切れない特殊な業務フローがあり、かつそのフローが病院の強みになっているケースも存在します。

ispecは、そのような課題を持っている病院様に対して、業務フローをヒアリングするところから始め、PdM、EM、エンジニアが一体となってシステムを作り上げていきます。

現在、以下の2つの開発を行なっています。

バックエンドの言語選定

これまでispecでは元々Go言語を採用することが多かったのですが、今後医療ドメインのプロジェクトを増やしていくにあたり、以下の理由でKotlinの知見を貯めていく意思決定をしました。

  • 国が提供する医療DX基盤との接続モジュールがJava/C#で提供されているため、Kotlinから簡単に呼び出せる
  • sealed class等の言語機能を利用することで直和型を簡単に実装できる (ex. Kotlinのsealed classで、複雑な医療ドメインをスッキリ管理)
  • 過去に電子カルテを開発した際にJavaを使った経験のある開発者が採用市場に一定数いる

また、サーバーのコード設計はおおむね以下のような方針で行なっています。

  • ドメイン駆動設計をベースにし、業務ロジックをドメイン層に凝集
  • kotlin-resultを採用し、Railway Oriented Programmingの考え方を取り入れたエラーハンドリング

業務ロジックやエラーハンドリングが複雑になる傾向があるため、Railway Oriented ProgrammingとDDDの合わせ技で設計をしています。

システムアーキテクチャおよびインフラの技術選定

データベースはPostgreSQLを採用しています。理由は単純にマルチテナントの医療システムを開発する際にRLS(Row Level Security)を使いたかったためです。 元々はMySQLをずっと採用していましたが、RLSを使う選択肢を常に持っておけるように、どんなシステムでも基本的にはPostgreSQLを使っています。

インフラは基本的にAWSを使っており、ECS Fargateをメインに使用しつつ、インフラ費用の要件や非同期処理等の要件に応じてLambdaを使っています。

デプロイ管理ツールはecspressolambrollを使っています。task definitionやlambdaの設定をアプリケーション開発者側が管理しやすいようになり、Terraformをかけるエンジニアが少ないispecにおいては非常に重宝しています。

クラウド型電子カルテを開発するベンダー様への開発支援

クラウド型電子カルテ(主に病院向け)の開発は、機能量の多さと求められるシステムの安定性、ドメイン知識などが求められるため、開発難易度は非常に高いです。ispecは、ベンダー様が開発に困っている箇所に対して、これまでの開発実績と医療ドメインの知識を活かして支援をしています。

支援の内容はベンダー様のニーズやタイミングによって異なりますが、これまでは以下のような内容を行なっています。

  • システムの信頼性を上げるための監視基盤・自動テスト基盤の導入
  • クラウドのシステム開発に適したアジャイルな開発プロセスの導入
  • 電子カルテから国が提供する医療DX基盤とつなぎこむためのマイクロサービスの設計・開発

クラウド型の医療システム開発支援においては、電子カルテのシステムに対して手を加える場合はベンダー様の技術に合わせていますが、新しく監視基盤やテスト基盤を作る場合は自分たちで最適な技術を選定しています。

サービス2. AIを活用した医療機関DX支援

AIを利用した医療機関DX支援では、AI/LLMを活用した医療機関向けのプロダクト開発を行なっています。現在は、在宅医療向けの医療事務AI SaaSの提供を開始しており、ステルスでもう一つのプロダクトの検討を進めています。

ここでは前者の在宅医療向けの医療事務AI SaaSの技術スタックを簡単に紹介します。

在宅医療向けの医療事務AI SaaS

在宅医療向けの医療事務AI SaaSは、主に以下のような機能を提供しています。

  • 医療機関にFAXで送られた情報をPDF化しs3にアップロード
  • アップロードされたPDFをLLMを用いて構造化
  • 構造化した情報を一覧で見れるように管理

システムアーキテクチャは以下のようになっています。s3アップロードをトリガーにしたイベント駆動のようなアーキテクチャになっています。
Image

ざっくりの技術選定は以下です。基本的にはこれまでの医療システム開発支援で使ってきた技術を流用しています。

  • フロントエンドはReact + Next
  • バックエンドはメインのAPIサーバーをKotlin、LLM処理部分をPython
  • バックエンドのメインサーバーはECSを利用し、LLM処理部分はLambdaを利用
  • データベースはAurora PostgreSQL
  • デプロイはエスプレスタック(ecspresso, lambroll)を利用

今後は電子カルテへの連携やFAX以外の情報の連携等も見据えており、そのために構造化処理(PDF Structurize)と構造化された情報を管理するバックエンド(API)を分離しています。

今後の技術的な展望

ispecは今後も事業を拡大するに当たり複数の方向を模索・検証していますが、その中で事業ごとに注力したい技術的な方向性を簡単に紹介します。

クラウド型医療システムのモジュール化・プラットフォーム化

クラウド型医療システム開発支援の方は、現在支援をしている電子カルテだけではなくリハビリや調剤業務に関わる周辺のシステム(部門システムと呼ばれます)の開発にも拡大をしていく予定です。

現在の部門システムのほとんどがオンプレミスのため、電子カルテがクラウド化されても部門システムがオンプレミスのままではシステム間の連携にコストがかかってしまいます。システム間のシームレスな連携を実現するためには、部門システムのクラウド化は必須です。

そのため、開発チームとしては以下のような技術的な展望を考えています。

  • 部門システムを含めた医療システム全体および業務フローのドメイン知識を蓄積する
  • 医療システムとして共通する部分をモジュールないしプラットフォームとして切り出しクラウド化のスピードを上げる

ドメイン知識を活用したAI/LLMアプリケーションの信頼性担保

AIを活用した医療機関DX支援の方は、現在は在宅医療向けの医療事務AI SaaSを開発していますが、他のプロダクトも同時に検証をしています。医療機関内でAI/LLMを活用する際には、以下のような課題があります。

  • ミッションクリティカルな業務において精度や可用性をどう担保するか
  • 病歴等の要配慮個人情報の取り扱いをどうするか

現在は提携先の医療機関に足を運んでドメインにディープダイブをしつつ、プロダクトを開発していますが、上記のような難しさも感じています。LLMを実際のアプリケーションに落とし込むためのデザインパターン等は、技術領域として強めていきたいと考えています。

1
ispec inc.

Discussion

ログインするとコメントできます