2040年の医療、誰がつくる？エンジニア視点で見る電子カルテの再設計

はじめまして、株式会社ヘンリーで VP of Engineering を務めております戸田と申します。弊社は中小病院の方々に向けて、医療情報システムやサービスを提供しているスタートアップです。私はフルスタックエンジニアとして、前職から続けて18年間にわたり基幹システム開発に携わってきました。

ITエンジニアとして日々コードを書き、システムを運用していると、つい自分の専門領域の中だけで世界を捉えてしまいがちです。しかし社会には、普段の仕事では触れることのない領域が数多く存在します。そのひとつが「医療」です。診察券を持ち、病院で待ち時間を過ごした経験はあっても、医療現場のシステムがどのように作られているかを知る機会はあまりないでしょう。

ところが、今後15年の日本において医療は大きな変革期を迎えます。その変化の背景には、私たちITエンジニアにとっても馴染みのある「技術選択」や「システム設計」の問題が横たわっています。本稿では、普段は触れることのない医療情報システムの世界を、ITエンジニアの視点から覗いてみたいと思います。

これからの15年間で大きく変わる日本の医療

まずは日本社会が直面する大きな前提から始めましょう。日本の総人口は減少局面に入って久しく、特に労働人口（15〜64歳の人口）は今後さらに減っていきます。厚生労働省の推計^[1]によれば、2020年から2040年の間に2割弱の労働人口が失われるとされています。

この傾向は地方においてより強く、たとえば長崎医療圏においては、2020年から2040年（推計）にかけて生産年齢人口が約3割減少すると試算されています。

地域医療情報システムによる、長崎医療圏における将来推計人口のデータ

人口が変化すれば、医療や介護の需要についても同様に変化が見られます。同じく長崎医療圏の医療介護需要予測を見ると、2020年から2040年にかけて医療需要はやや減少するも労働人口の減少ほどではなく、介護需要は現状よりも増加すると予測されています。労働人口が3割減る一方で需要はそこまで減らない、すなわち生産性の向上が必須だと見込まれているわけです。

地域医療情報システムによる、長崎医療圏における医療・介護の需要予測

こうしたデータは日本医師会が提供する地域医療情報システム 「jmap.jp」 で簡単に知ることができますので、ぜひ読者の皆さんのご実家やゆかりのある地方について調べてみてください。日本の医療では大きく市場が変わってきていて、従来のやり方では維持すらできない未来へと突入しているのだなと感じていただけると思います。

変化に対応するための投資が行えない医療機関

しかし、変化に対応するための投資を行おうとしても、多くの医療機関にはその余力が無いのが現状です。むしろ経営の困難さが年々増しており、実に6割以上の病院が赤字だという調査結果^[2]があります。

また、医療機関の倒産件数も増加傾向にあります。帝国データバンクの調査^[3]によれば、2025年上半期の医療機関の倒産件数は過去最多のペースで推移しています。背景には人件費や物価の高騰がある一方で、収入の伸びが限定的であり、収益改善が困難なことが挙げられます。

なぜ物価上昇局面にあっても収入が伸びないのでしょうか？医業収入の大部分を占める診療報酬は国が価格を一元的に管理しており、医療機関が自由に売上を拡大する施策を打つことは難しく、収益改善の余地が非常に限られているためです。新規サービスや価格改定で柔軟に収益を伸ばすことができる一般企業とは根本的に異なるのです。

次に、医療機関における人件費の比率が総費用の5割を超えることも経営を圧迫しています。人材不足を背景に賃上げが社会的に求められる一方で、前述のとおり収益が伸びないため、十分な賃上げを行う余力が限られています。

事実として医療業の賃上げや給与額は産業全体と比べても見劣りするものとなっており、採用や待遇改善などの投資を行うことが難しい状況にあることがわかります。また、投資のための余力を生み出すことができれば業界全体への良い貢献になることも明らかだと考えられます。

中央社会保険医療協議会 総会（第607回）資料「医療機関を取り巻く状況について」より引用、医療業の給与額が他産業よりも伸びていないことがわかる

オンプレミス型電子カルテが抱える構造的な課題

このように医療業界においては省力化・効率化が強く求められる状況があり、ITシステムによる貢献が期待されていることは明らかです。事実として国も医療DXを推進して業務効率化を成し遂げようとしています^[4]。特に電子カルテについては中小病院における普及率が2023年時点で5割強に留まるため、「医療DXの推進に関する工程表」では遅くとも2030年には概ねすべての医療機関において電子カルテの導入を目指すとされています。

しかしここで問題を深刻化させているのは、従来のオンプレミス型電子カルテが抱える構造的な課題です。これらのシステムは初期導入費用が高額なだけでなく、カスタマイズや機能追加のたびに多額の費用が発生します。また、多くの医療機関には専任の情報システム管理者が存在しないため、システムの導入や更新が外部ベンダーに強く依存し、そのつど高額な費用が発生します。

さらに、オンプレミスのシステムでは古いソフトウェアやハードウェアを使うことが多くあります。たとえば、ランサムウェア攻撃にあった国内の病院の報告書を紐解くと、サポートが切れた技術基盤やOSに依存したシステムが未だに現役であること、むしろそうしたサポートが切れたシステムの新規導入すら提案されるという状況が見えてきます^[5]。

電子カルテシステム、部門システム、医療機器など、確認したほとんどのシステムや機器で、最新のバージョンの OS は利用されておらず、パッチも適用されていなかった。また、既にサポートが切れた OS の利用なども確認された。

（中略）

2013 年頃にセンターに、新規で導入された複数の医療機器の制御端末の OS が Windows 2000 であった。

こうした既知の脆弱性があるシステムを利用するために閉域網が求められ、インターネットに繋がらないので数多くの不便が生まれ、生産性を落とす結果となっています。

スタートアップがクラウド型電子カルテを作る意義

ここまでで、日本の医療は2040年までの15年で大きく変化することが求められていること、その一方でほとんどの医療機関は変化に対応するための投資が行えない状況にあること、DXが強く望まれる一方で既存システムに課題が多いことを見てきました。弊社はこの課題に対して、クラウドネイティブな医療情報システムを実装・提供することで切り込んでいます。

2040年を見据えた医療の課題と、その解決に向けて立ちはだかる障害

たとえば、クラウドネイティブのシステムであれば院内のハードウェアを減らし効率よく計算機資源を使えるようになるため、システム管理の手間とコストを抑えられます。

オンプレミスであれば5年後のピークタイムでも問題なく稼働するようにハードウェア性能や記憶容量を調達する必要があります。電子カルテであれば5年後の患者数や診察数を想定し、その時点で最も計算機資源を必要とする処理に必要なハードウェア性能を見積もって、これを購入するわけです。システム更新時にはスケールアップやハードウェア更新費用もかかりますし、国全体でマクロにみるとこうしたコストが医療機関の数だけかかることにもなります。

一方でクラウドネイティブなサービスであれば、必要なときに必要なだけ計算機資源を従量課金で調達できます。マルチテナントのシステムであればさらにランニングコストを圧縮できます。5年待たずとも最新のハードウェアに順次乗り換えることもできますし、マネージドサービスを活用すればOSやログなどを管理する手間やシステムを更新する手間を省くこともできます。

弊社製品のとある1日におけるインスタンス数の遷移。外来受付が始まる朝9時前後から負荷が上がっていること、夜間はその3割程度でサービスが安定的に稼働していることがわかる。

この他にもサーバを始めとした多くの構成要素がベンダーである弊社の管理下にあるため医療機関の皆さんにとって管理する対象が減らせること、DoS攻撃対策やサプライチェーン攻撃などにクラウドサービス事業者の高い技術力を適用できること、院内における閉域網の必要性が減って最新のOSやブラウザが使えるようになること、脆弱性対応を迅速に行えるため院内で管理しているシステムよりも安心できることなど、クラウドネイティブなサービスにはオンプレミスのシステムに対して様々な利点を備えています。

私たちが新しいアプローチを市場に持ち込むことで病院における業務にも新しい技術や運用がもたらされ、2040年でも安心して医療を受けられる未来が実現できるようになるはずです。スタートアップが今までにない技術を医療業界に持ち込んで課題を根本から解決することの意義が伝われば幸いです。

クラウドネイティブはオンプレミスな医療情報システムの課題を解消できる

レセコン一体型電子カルテ「Henry」の構成技術

では我々が実装・提供するサービスを構成する技術を見ていきましょう。本記事執筆時点でレセコン一体型電子カルテ「Henry」はGoogle Cloudの東京リージョンを中心として稼働しています。アプリケーションサーバはCloud Runで稼働し、データベースとしてCloud SQL for Postgres、ストレージとしてCloud Storageを採用しています。

アーキテクチャは次の図のように、とてもシンプルなものです。また図には登場しませんが、可観測性のためにDatadogとHoneycomb、Sentryを採用しています。

単純化された「Henry」のアーキテクチャ。実際にはこのように独立した機能を持つCloud Runが10以上存在する。

データ分析用のBigQueryもあり、Cloud SQL federationによってCloud SQLのデータを参照しています。病院における意思決定には売上のレポートや分析はもちろん、病床稼働率のような指標も多く必要となるため、より大きなお客様にご利用いただくためにもBIは非常に重要であると考えています。

お客様の業務フローが診療報酬制度という太い幹で貫かれているため、医療情報システムはドメイン境界がわかりにくく、気を抜くと密結合になりがちという特徴があります。たとえば審査支払機関に送付する請求用ファイルを作成する「請求レセプト」モジュールや、院内のワークフローを一手に引き受ける「オーダー」モジュールなどがありますが、すべて診療報酬制度に依存しています。モジュールひとつひとつの専門性も高く実装は困難です。

このためトップダウンでアーキテクチャを決めるのではなく、ITエンジニア全員がアーキテクト的な視点でボトムアップに探索していく方針としています。ITエンジニアはADR (Architecture Decision Records)を書くことでチームやモジュールを超えて設計について提案・議論しています。

フロントエンドは Next.js + React + MobX を、バックエンドでは Ktor + Koin + Exposed を主なフレームワークとして利用しています。Reactのルーターを自前で実装している点やMobXを採用している点に弊社サービスの特徴が色濃く現れていると言えるでしょう。

医療情報（要配慮個人情報）を扱う関係で高い非機能要件が求められており、データの履歴を持つ、複数リージョンに保存する、アクセスログを分析可能な形で残しておく、といった設計上の工夫も多数あります。

Henryを作るエンジニアリング組織

Henryが挑むドメイン領域はとても広いため、中央集権的に意思決定するのではなく、エンジニアリングチーム自ら意思決定できるようにすることが重要だと考えています。

次の図を見てください。これは架空の業務フローですが、医療における業務フローはこのように縦（職種）と横（段階）の両軸において複雑なものです。したがって医療ドメインにおける課題解決はナタで割るようにはできず、ひとつひとつ向き合うことが必要になります。このためさきほどのアーキテクチャの話と同様に、トップダウンでの意思決定が有効な部分はかなり限定的で、高いモチベーションを持つチームが現場と現実に向き合って自ら意思決定し、課題解決をすることこそが必要になると考えています。

業務フローのイメージ。多くの業種が連携して物事を進める様を表現している

ヘンリーではこのようなチームでの意思決定を強力に推進するために、組織設計とDevOpsの両面から工夫をしています。

ミドル・アップダウン・マネジメントを中心とした組織設計

組織設計の観点では、野中先生が著書で提示されたミドル・アップダウン・マネジメントを念頭に置いています。SECIモデルを組織全体で回すものであると考えていただけるとわかりやすいかもしれません。

ミドル・アップダウン・マネジメントにおけるミドルの主要な仕事は、このカオス的状況をある目的のための知識創造として方向づけることだ。つまり、部下たちにある概念枠組みを与え、自らの経験の意味を理解できるように彼らを助けるのである。

しかし、ミドルが創る概念枠組みは、トップのそれとはかなり異なる。後者は、会社がどこをめざすべきか、という方向感覚をもたらす。ミドル・アップダウン・モデルでは、トップはビジョンや夢を描くが、ミドルは第一線社員が理解でき実行に移せるようなもっと具体的なコンセプトを創り出す。（新装版 知識創造企業 216ページ）

私たちの組織は経営とミドルマネジャー、そしてIndividual Contributorというとてもシンプルな3層構造です。ここでどのようなコミュニケーションが発生するのか見てみましょう。週2回開催される経営会議で全社的な課題について議論して意思決定を行い、それをミドルマネジャーや全体に対して共有するところから始まります。

ミドルアップダウンマネジメントの概念図

cross-functionalチームを中心としたDevOpsの実践

DevOpsの観点では、デリバリーに必要な機能すべてを各エンジニアリングチームが備えるようにしています。もちろんアーキテクチャチームや品質保証チームのような、Centers of Excellence体制で臨むことにも一定の利点はあるとは思います。しかしState of DevOps 2019 レポートで報告されているようにサイロ化を生むことが懸念されること、各チームの専門性が高く探索的な意思決定が求められることから、できるだけエンジニアリングチームに意思決定させられるように心がけています。

サービスに関する意思決定はできるだけエンジニアリングチームに寄せて、プラットフォームチームで支援や連携をしている

なお同様の考えからプラットフォームSREでは、エンジニアリングチームへのenablingが重要だと考えています。詳細は割愛しますが、よろしければこちらの資料をご覧ください：

最後に、ヘンリーがcross-functionalなチームを作るうえで最も特徴的な意思決定は、ドメインエキスパートと呼ばれる医療事務や看護師のご経験をお持ちの皆さまをエンジニアリングチームに配属していることです。お客様にヒアリングすることももちろん行いますが、知識と経験を持った専門家が身近にいて一緒に物事を解決してくれることの心強さには代えがたいものがあります。医療未経験のITエンジニアが短い時間で成果が出せているのも、ドメインエキスパートの皆さんのご支援に依るところが大きいと考えています。

株式会社ヘンリーは2040年の医療をエンジニアリングで創っていきます

2040年に向けて日本の医療に変化が求められていること、病院がそのための投資さえなかなか行えない状況にあることを踏まえて、医療DXに寄せられる期待を見てきました。また弊社がなぜクラウドネイティブな医療情報システムによってこの社会課題が解決できると考えているかを述べ、そのエンジニアリングを支える技術と組織について見てきました。

みなさんが生活において活用されている医療機関の背景にこのようなトレンドとシステムがあることや、医療従事者のみなさんが直面している課題についてご理解いただき、みなさんが2040年の未来について考える一助となれば幸いです。