電子カルテ標準仕様書で求められるアーキテクチャ・非機能要件を整理してみた
いわさです。
先日のさっぽろ医療IT勉強会 #2 に参加しました。
勉強会で電子カルテ標準仕様について触れる機会があり、改めて仕様書の中身を読み込んでみました。
内容を整理しておきたかったので記事にします。
2026年3月に厚生労働省から電子カルテ及びレセプトコンピュータの標準仕様書（基本要件）第 1.0 版が公表されています。
仕様書は「医科診療所向け」と「中小病院向け」の2種類があり、遵守要件の内容は共通です（本記事では別紙が充実している中小病院向けを取り上げます）。
大規模病院向けは別途「病院情報システム等の刷新に向けた協議会」[1]で検討中ですが、仕様書は未公表です。
これらの仕様書は、電子カルテ市場の高コスト構造やベンダーロックイン（特定の業者に依存して乗り換えが困難な状態）、医療機関間の情報連携の断絶を解決するために策定されたとのことです。
背景には、2025年12月の医療法改正で「2030年12月31日までに電子カルテ普及率 100%」という法定目標が設定されたこともあります。
準拠自体は法的義務ではないのですが、準拠していないと診療報酬加算（医療機関の収入に上乗せされる点数）が取れなくなるため、電子カルテベンダーにとっては事実上の必須要件になりそうです。
今回こちらの仕様書を読み込んで内容を整理してみたので紹介します。
仕様書の全体像
仕様書は第1章「電子カルテ標準仕様書」と第2章「レセプトコンピュータ標準仕様書」で構成されており、それぞれに機能要件・非機能要件・アーキテクチャ・データ移行・システム間連携・情報提供に関する要件が含まれています。
なお、レセプトコンピュータとは診療報酬の請求（レセプト作成）を行うシステムのことです。
要件には4つの類型が定義されています。
- 遵守: 準拠を名乗るには全項目に適合が必要
- 推奨: 未対応でも準拠は名乗れる。将来「遵守」に昇格する可能性あり
- 不可: 該当すると準拠を名乗れなくなる（v1.0 では該当なし）
- 参考: 今後「遵守」「推奨」になりうる検討中情報
v1.0 で「遵守」として必須になっている要件を中心に見ていきます。
「推奨」「参考」類型の要件については、記事の後半で「今後遵守に格上げが見込まれるもの」として触れます。
アーキテクチャ要件
クラウドネイティブを前提とした設計が求められており、仕様書によると以下が「遵守」として定められています。
- ガバメントクラウド対象 CSP のパブリッククラウドで稼働すること（AWS/GCP/Azure/OCI/さくらが対象）
- SaaS 型であること
- マルチテナント方式であること（仕様書上、シングルテナントは認められていません）
- ソースコードは全テナント共通であること
- 個々の医療機関向けのカスタマイズは不可（設定変更やオプション機能の有効/無効切り替えは可）
- デジタル庁 GCAS ガイド「モダン化の定義」に合致すること
マルチテナントとは、1つのシステムを複数の医療機関で共同利用する方式です。
医療機関ごとにシステムを個別構築するシングルテナントは仕様書では認められていません。
マルチテナントの実現方式（データベースを全医療機関で共有するか、医療機関ごとに分けるか等）については規定がないので、ここは各ベンダーの設計判断に委ねられています。
仕様書の背景説明によると、従来の電子カルテは医療機関ごとに大量のカスタマイズが入っていて、それが高コストの原因のひとつだったとのこと。
「設定で対応、個別改修はしない」という SaaS 的な方針が仕様として定められた形ですね。
GCAS ガイド「モダン化の定義」
仕様書がアーキテクチャ要件として参照しているのが、デジタル庁の GCAS（Government Cloud Advisory Services）ガイドで定義された5つの要素です。
- API ベースのシステム構成: REST API で疎結合化。フロント/バックエンド分離
- ステートレスなアーキテクチャ: サーバに状態を持たせない。コンテナ活用。オートスケール
- マネージドサービスの活用: クラウドのマネージド DB・キュー・ストレージ等を利用
- 運用のコード化・自動化: IaC（Infrastructure as Code: インフラ構成をコードで管理する手法）。Zero Touch Production
- サービスレベルの定義・計測: KPI 定義→計測→振り返り→改善のサイクル
Zero Touch Production（本番環境に人間が直接ログインせず、全ての変更をコード化・自動化されたパイプライン経由で行う）が遵守要件に含まれています。
クラウド外に置いてよいもの
全部クラウドに載せなければならないわけではなく、以下は例外として認められています。
- 資格確認端末・プリンターとの通信中継
- 見読性担保のためのデータ保管（法律で「カルテを目で読める状態で保存すること」が求められており、そのためのローカル保存）
- クラウド障害時の事業継続機能（例: ローカルキャッシュで直近の患者情報を端末に保持し、クラウド停止時も参照可能にする等）
非機能要件
非機能要件も「遵守」として数値や条件が定められています。
可用性は稼働率 99.9% 以上（年間停止 約8.7時間以内）。
セキュリティ面では、ISMAP（政府情報システムのセキュリティ評価制度）又は ISMS 認証（情報セキュリティマネジメントシステムの国際規格 ISO 27001 に基づく認証）+ ISMS クラウドセキュリティ認証の取得が必要です。
加えて、第三者機関によるペネトレーションテスト（外部のセキュリティ専門業者が実際に攻撃を試みて脆弱性を洗い出すテスト）の実施が遵守とされています。
仕様書の文面上は「第三者機関」となっているので、自社実施ではなく外部への委託が求められている形です。
脆弱性診断は政府脆弱性診断導入ガイドライン準拠で実施、セキュリティパッチは定期適用に加え緊急時は即時適用。
データ保管は日本国内で保持し海外送信不可。バックアップは物理的・論理的に隔離された別サーバ又は外部メディアに定期バックアップ。
「データ国内保管・海外送信不可」が明確に書かれているので、AWS であれば東京リージョン（と大阪リージョン）に閉じる構成になりますね。
なお、仕様書は「医療情報システム安全管理ガイドライン第6.0版」に準拠した上で、さらに追加の要件を課す形になっています。
ガイドラインでは具体的な数値目標がなかったり認証取得が推奨レベルだったりするのですが、仕様書ではそれらを遵守レベルに引き上げています。
機能要件（外部接続）
機能要件で遵守とされているのは、院内の機能ではなく「外の世界と繋がる」ための4つの接続要件です。
- オンライン資格確認等システム: マイナ保険証での保険資格確認
- 電子処方箋管理サービス: 処方データの電子送受信
- 電子カルテ情報共有サービス: 3文書6情報を HL7 FHIR 形式で送信
- クラウド型レセプトコンピュータ: 共通算定モジュールとの接続
3文書6情報というのは、診療情報提供書・退院時サマリー・健診結果報告書の3文書と、傷病名・アレルギー・感染症・薬剤禁忌・検査・処方の6情報を指します。
電子カルテ情報共有サービスへの接続では HL7 FHIR（R4 + JP Core）が使われます。
これは異なるシステム間で患者情報を共通の形式でやり取りするための国際標準規格で、RESTful API + JSON 形式でデータを交換します。
例えば GET [base]/Patient/12345 で患者情報の JSON が返ってくるようなイメージです。
日本向けに項目を定義した「JP Core」プロファイルが用意されています。
経過措置として、電子処方箋と電子カルテ情報共有サービスへの接続は「民間カルテにもクラウド間連携が開放されたと国が公表した日」から6か月間は推奨扱いになるとのことです。
この「開放」の時期は未定で、2026年度冬の全国展開前後ではないかと言われていますが公式なアナウンスはまだありません。
今後遵守に格上げが見込まれる要件
ここからは v1.0 時点で「推奨」または「参考」に分類されている要件です。
現時点では未対応でも準拠を名乗れますが、次版以降で「遵守」に格上げされる可能性が高いものが含まれているため、設計段階から意識しておくと手戻りが少なくなりそうです。
なお、前述の電子処方箋・電子カルテ情報共有サービスへの接続も、クラウド間連携の開放日から6か月経過後には「遵守」に切り替わります。こちらは時限的な経過措置なので、実質的には遵守と考えて準備しておくべきものですね。
「推奨」類型の主な項目
仕様書本体を確認すると、v1.0 で「推奨」として定義されている項目のうち主なものを挙げます。
機能面では、電子処方箋の追加機能（処方箋取消UNDO、変更、重複投薬チェック事前処理等）、患者サマリー登録・閲覧サービス機能、主治医意見書電送機能などがあります。
非機能面ではウェブアクセシビリティ導入ガイドブックの「重大な悪影響を及ぼすもの」「必ず達成しなければならないもの」への適合が推奨されています。
外部接続では、共通算定モジュールとの連携（カルテ一体型は除く）、介護情報基盤との接続が推奨です。
情報提供・公開の分野では「外部ベンダー向けの開発・テスト環境の整備・公開」が含まれています。
これが将来遵守に格上げされた場合、API のサンドボックス環境を外部に公開する必要が出てくるので、アーキテクチャに影響しそうなポイントです。
データ移行（参考）
v1.0 時点では「参考」類型なので遵守ではないのですが、仕様書に「次版以降において遵守を設定予定」と明記されています。
ベンダー乗り換え時のデータ移行を効率化し、ロックイン解消を狙った仕様とのこと。
共通データ移行レイアウトとして、CSV 形式（UTF-8、BOM なし、RFC 4180 という CSV の標準的な書式ルールに準拠）のエクスポート仕様が例示されています。
移行対象は患者基本情報、病名、検査結果、処方オーダ、注射オーダ、文書・記録など。
これが遵守になると、どのベンダーの電子カルテでも共通フォーマットでデータをエクスポートできるようになるので、乗り換えのハードルが大きく下がりますね。
システム間連携（参考）
v1.0 で遵守なのは前述の外部接続のみですが、仕様書には今後の方向性として API 仕様例が添付されています。
部門システム間 API（患者基本情報取得、患者プロファイル情報取得）や、業務効率化サービス API（予約・受付管理、WEB 問診、音声認識・AI 文書生成などとの連携）がユースケースとして定義されています。
いずれも v1.0 では「次版以降において設定予定」とだけ記載されており、遵守にも推奨にも未分類です。
ただ、API は FHIR 準拠 JSON 形式で、エンドポイント例として GET [base]/Patient のような記述があるので、方向性は見えています。
これらが遵守に格上げされると、電子カルテの API 公開が事実上必須になるので、サードパーティとの連携が進みそうです。
AI 文書生成サービスが電子カルテに直接診療記録を登録する、というユースケースが仕様書の中で定義されています。
ガバメントクラウドと認証制度
ガバメントクラウド対象 CSP と公共 SaaS の違い
アーキテクチャ要件に「ガバメントクラウド対象 CSP のパブリッククラウドで稼働」とありますが、「ガバメントクラウドの契約枠（公共 SaaS）で構築しなければならない」という意味ではありません。
通常の AWS アカウントで構築してもよいし、ガバメントクラウド上の公共 SaaS として構築してもよい。
公共 SaaS として構築した場合はアーキテクチャ要件やセキュリティ要件の一部（ISMAP 認証、第三者ペネトレーションテスト、脆弱性診断）が「適合しているものとみなす」扱いになるので、認証取得のコストを省略できるメリットがあります。
逆に、公共 SaaS でも免除されないものとしては、セキュリティパッチの定期適用、データ国内保管・海外送信不可、バックアップの隔離、ガイドライン準拠、機能要件（外部接続4つ）があります。
認証制度の現状
仕様書では、遵守類型の全項目に適合していれば「準拠を標榜」できると定義されています。
では誰がその適合を確認するのかという点ですが、厚労省のポータルサイトに「認証制度」のセクションが設けられており、以下のように記載されています。
認証制度の詳細につきましては、今後掲載いたします。
つまり、認証制度自体は設けられる予定ですが、2026年8月時点では制度の詳細（自己宣言なのか第三者認証なのか、審査主体は誰か等）は公表されていません。
仕様書本体にも認証プロセスに関する規定はなく、「仕様書の遵守項目をすべて満たしていれば準拠を名乗れる」という定義があるのみの状態です。
スケジュールと診療報酬加算
主なタイムラインとしては、2026年3月に仕様書 v1.0 公表、2026年6月に「電子的診療情報連携体制整備加算」施行、2026年度冬に電子カルテ情報共有サービス全国展開目標、2030年12月に全医療機関で電子カルテ導入100%（法定目標）となっています。
医療機関側のインセンティブとして「電子的診療情報連携体制整備加算」が2026年6月から施行されています（旧「医療DX推進体制整備加算」と「医療情報取得加算」を統合・再編）。
加算の具体的な点数としては、加算1（電子処方箋＋電カル情報共有サービス＋医療情報連携ネットワークの全てに対応）で初診料 15点・再診料 2点、加算2（いずれかに対応）で初診料 9点・再診料 2点、加算3（オンライン資格確認＋マイナ保険証利用率30%以上等の基本要件のみ）で初診料 4点・再診料 2点です。
1点＝10円なので、加算1を算定できる医療機関であれば初診時に150円、再診時に20円が上乗せされます。
入院については初日に加算1で160点、加算2で80点が算定できます。
準拠製品を導入し電子カルテ情報共有サービス等と連携している医療機関は診療報酬を追加で算定できるので、医療機関からベンダーに対して「準拠製品にしてほしい」という要求が出てくる構図です。
現時点で未確定の事項
仕様書の中で、v1.0 時点で具体的な仕様が示されておらず「次版以降」とされているものを整理しておきます。
クラウド間連携の接続方式（SaaS から国のシステムに直接つなぐ際のネットワーク方式）が未公表です。
VPN なのか相互 TLS（サーバとクライアントの双方が証明書を提示して互いに認証する方式）なのか、あるいは別の方式なのかが示されていません。
「民間カルテにもクラウド間連携が開放された」旨の公表を待つ形で、時期も未定です。
データ移行レイアウトは CSV エクスポートの共通レイアウトが「参考」として例示されていますが最終仕様は未確定。
部門システム間 API と業務効率化サービス API は仕様例が別紙に添付されているものの遵守にも推奨にも未分類で、「次版以降において設定予定」とだけ記載されています。
方向性と例は示されているので「何を実装するかの見当はつくが、最終仕様に合わせて手直しが必要になる可能性がある」という状態です。
さいごに
本日は 2026年3月に公表された電子カルテ標準仕様書（第 1.0 版）の内容を整理してみました。
アーキテクチャ要件（SaaS/マルチテナント/GCAS モダン化）と非機能要件（99.9%/ISMAP/データ国内保管）は v1.0 で遵守として確定しているので、今すぐ設計・実装の方針を立てられる状態です。
未確定の部分は次版以降の公表待ちですが、方向性と例示は出ているので、大きく外れることはないだろうと思います。
今後の改定も追いかけていきたいと思います。
