標準型電子カルテとは？標準規格に準拠したクラウドベースの電子カルテであり､電子カルテ情報の共有のために最低限必要な機能を備えたものです。「骨太の方針2023」では、医療DXの推進における具体的な施策の1つに標準型電子カルテの整備があげられました。医療機関にとっては、電子カルテは非常に高額な投資です。標準型電子カルテが本格稼働するまで、電子カルテの導入や更新の様子を見ている法人様も多いのではないでしょうか？普及までのスケジュール2023年度に厚生労働省にて必要な要件定義等の調査を行い、2024年度にデジタル庁にてα版のシステム開発に着手します。2024年4月12日、株式会社FIXERはデジタル庁より「標準型電子カルテシステムα版の設計・開発業務」を受託し、契約を締結しました。2025年度にはα版の提供が開始され、試験的運用が開始されます。出典：第4回「医療DX令和ビジョン2030」厚生労働省推進チーム資料（8月30日）資料2－3 今後の進め方（矢羽根詳細）.pdfhttps://www.mhlw.go.jp/stf/newpage_34874.htmlFIXERとは？FIXERは2009年創業の基幹システムのクラウド構築やクラウド移行･保守運用サービスを展開している会社です。FIXERが提供する生成AIプラットフォーム「GaiXer」は、クラウド上のセキュアな専用環境でデータを処理するほか、多彩な付加機能も搭載しているため自治体での導入が進んでいます。また、2月から順天堂大学との生成AIを活用した医療DXの共同研究をもスタートさせています。GaiXerを利用して電子カルテの情報をもとに診療報酬算定の労力を減らすため、仕組み作りの研究を行っているところです。電子カルテのベンダーではないものの、クラウドや生成AIに熟知した会社であり、行政や自治体との関係性も強い会社のようです。標準型電子カルテ開発の範囲開発期間が1年ということもあり、α版は無床診療所を想定しています。つまり、入院関係の機能はα版では開発されません。また、最小限の機能を提供しつつ他のシステムやサービスとの連携を目指しています。ですから、最大公約数のシステム開発になり、特有の機能が必要な場合は以下の選択を迫られることになります。・標準電子カルテにオプションを付ける（未開発かつ未提供）・部門システムをカスタマイズする・紙を併用し、人海戦術で対応する「標準型電子カルテ検討技術作業班」のディスカッションでは、UIも民間のサービスに依頼する話が出ていました。標準型電子カルテ普及の狙い現在電子カルテの普及が進んでいない、下図の病床数200床未満の中小病院または診療所が対象になります。2030年までに導入させることが目標です。出典：電子カルテシステム等の普及状況の推移.pdf（厚生労働省）https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/kenkou_iryou/iryou/johoka/index.htmlでは、なぜ標準型電子カルテを開発してまで導入させたいのか。これは、全国プラットフォームで標準型電子カルテの情報を共有するためです。紙カルテのままでは全国プラットフォームに患者情報が集積できません。国が目指しているマイナンバーカード、電子処方箋、全国医療情報プラットフォーム、標準型電子カルテなどの医療DXのシステム群につながり、患者情報を閲覧できる環境を構築するために不可欠なのです。第4回「医療DX令和ビジョン2030」厚生労働省推進チーム資料（8月30日）資料2－2 全国医療情報プラットフォームの概要.pdfhttps://www.mhlw.go.jp/stf/newpage_34874.html医療DXの目的は、病院内の業務効率化だけではなく、全国医療情報プラットフォームに必要な情報連携をさせることが狙いとなっています。既存の電子カルテはどうなる？標準型電子カルテを開発する中で、全国医療情報プラットフォームとの連携に必要なモジュールを電子カルテベンダーへ提供することが検討されています。つまり、現在提供されている電子カルテは残り続けます。標準型電子カルテの課題以下の3点が、標準型電子カルテの開発で想定される課題です。① マスタの整備② 情報セキュリティ③ 収集するデータ1つ目のマスタの整理は、電子カルテと部門システムをAPIで情報連携するために必要となります。APIの基本的なプロセスは「リクエスト（要求）」と「レスポンス（応答）」で構成されます。リクエストとレスポンスに関するルールは、レスポンス側のAPIの提供者が定めます。つまり、何のリクエストに対してどんなレスポンスをするのかということを提供者がAPIの設計段階で考え、実装し、利用可能な状態にします。例えば、標準型電子カルテで検査結果のデータが欲しい場合、標準型電子カルテはリクエスト側であり、検査結果を収集し整理して渡す検査部門システムはレスポンス側になります。検査部門システムは複数のベンダーから提供されているため、それぞれのベンダーで「リクエストとレスポンスに関するルール」を設計し、ベンダー別の回答に電子カルテ側が対応するのは困難だと考えられます。部門システムの開発側に任せたAPI設計では情報連携が難しく、リクエストとレスポンスのやり取りを標準化するためのマスタ整備が必要となります。2つ目の情報セキュリティは、患者情報を守るために重要となります。標準型電子カルテのサーバーがDDos攻撃等を受けてクラッシュした場合、多くの医療機関で電子カルテが利用できなくなる可能性があります。また、標準型電子カルテの導入先で情報セキュリティ対策を行っておらず感染した場合、他の病院へ全国医療情報プラットフォームを介して感染する可能性もあります。閉鎖環境であれば安心という神話も、昨今のサイバー攻撃から揺らいできました。今後ますます、クラウドのシステムとオンプレのシステムとの連携により境界があいまいになることが想定されるため、各施設の万全な対策が求められます。医療機関等におけるサイバーセキュリティ対策チェックリストが令和6年5月に改訂されたため、セルフチェックしておくことをお勧めいたします。https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html3つ目の収集するデータは、全国医療情報プラットフォームに収集するデータのことです。3文書6情報（※）が現在連携したい情報の目標ですが、CTやMRI、エコーなどの画像情報を共有するのか、患者が測定した血圧などの情報も蓄積させるのか、といった追加情報が論点になります。なぜなら、ファイルサイズが大きい画像や高頻度で蓄積されるデータは、サーバーの容量を圧迫するからです。さらに、1つ目の課題と一部関連しますが、収集するデータが増えるたびにAPIのレスポンス内容が変わる可能性があります。それをどこまで想定して開発や設計を進め、既存のシステムと連携することができるかが重要となります。（※）3文書：診療情報提供書、退院時サマリー、健診結果報告書6情報：傷病名、アレルギー情報、感染症情報、薬剤禁忌情報、検査情報、処方情報まとめ入院機能を持たない診療所は、α版の開発範囲で十分網羅されるため標準型電子カルテが本格的に稼働し始めるまで待ち続けても問題ないと思われます。また、標準電子カルテが無償あるいは安価に提供されれば、民間企業が販売しているクリニック向けの電子カルテの価格が下がる可能性があります。一方で、入院機能を持つ医療機関は注意が必要です。入院機能はα版の開発範囲にありませんので、追加で開発されるのか、開発される場合の本格提供開始はいつ頃かになるのか確認が必要です。また、民間のベンダーがオプションとして開発する場合も十分想定できます。さらに、不足する機能をどこに負担させるかが焦点になり、標準電子カルテのオプションを購入する、部門システムをカスタマイズする、という2つの場合は、もちろん別途費用が掛かります。紙を併用し、人海戦術で対応する場合は、業務効率化はおろか業務が非効率になってしまう可能性があります。この点を踏まえたうえで、標準電子カルテ導入を検討いただきたいです。今後、民間の電子カルテ導入や更新を検討する際は、開発体制の確認が重要になります。モジュールを提供される可能性がありますが、医療情報プラットフォームへのAPI連携等の対応がありますので、ある程度の開発者数を持つベンダーを選定することをお勧めします。安いからと標準型電子カルテを導入した結果、たくさんのオプションを追加し、割高になってしまったとならないように注意が必要ですね。弊社では、医療情報システム（電子カルテと部門システム）の導入・更新についてご支援しています。ご興味・ご関心がある方はお問い合わせください。