医療SaaS FHIR連携完全ガイド【2026年版・HL7 FHIR/JP Core/電子カルテ標準化】

※本記事には広告（PR）が含まれます。mitoru編集部は公開情報を整理して比較・解説しており、表示順位や評価は広告主からの依頼ではなく編集部の独自判断によります。

医療SaaS（電子カルテ・予約・問診・検査・PHR・診療支援等）の選定で「FHIR対応」を要件に挙げる医療機関が増えています。背景には、厚生労働省が推進する「医療DXの推進に関する工程表」、全国医療情報プラットフォーム構想、電子カルテ情報共有サービス（仮称）、電子処方箋といった一連の制度設計が、HL7 FHIR（Fast Healthcare Interoperability Resources）を共通の医療情報交換規格として採用しているという事実があります。一方で、ベンダーが掲げる「FHIR対応」という言葉の中身は製品ごとに大きく異なり、選定担当者が表面的なチェックボックスだけで判断すると、実装段階で連携不能・追加開発費発生・JP Core非準拠といった問題に直面しがちです。

本稿では、HL7 FHIR規格の概要と標準化の歴史、日本実装ガイドである「JP Core」の現状、電子カルテ情報共有サービスへの接続、SS-MIX2との関係、主要電子カルテベンダーのFHIR対応状況の見方、SaaS選定時の比較観点、認証・同意・セキュリティ要件、自己解析チェックリスト、FHIR対応を急がない方が良いケース、FAQまでを公開資料ベースで整理します。特定ベンダー・特定製品を推奨する目的ではなく、選定担当者が判断軸を自ら持てるようにすることが本稿の目的です。

HL7 FHIRの概要と医療標準化の歴史

HL7（Health Level Seven International）は、医療情報の交換・統合・共有・取得を目的とした国際標準を策定する非営利団体で、1987年から活動が続いています。FHIRはHL7が策定する第4世代の医療情報交換規格で、Web標準技術（HTTP・REST・JSON/XML・OAuth 2.0等）を採用することで、従来のHL7 v2やHL7 CDAと比べてWeb開発者にとって扱いやすい設計になっている点が特徴です。FHIR R4（Release 4）が安定版として広く採用されており、後継のR5も順次普及段階にあります。

FHIRの構造は「リソース」と呼ばれる単位で表現されます。患者情報は Patient、診療予約は Appointment、観察・検査結果は Observation、医薬品の処方は MedicationRequest、というように、医療業務の概念ごとにリソースが定義されており、それぞれがJSONまたはXML形式で表現可能です。各リソースはHTTPのGET/POST/PUT/DELETE等の操作で取得・更新できるため、Webアプリケーション開発に近い感覚で医療情報連携を実装できることがFHIRの最大の特長です。

厚生労働省は「医療DXの推進に関する工程表」の中で、全国医療情報プラットフォームの整備、電子カルテ情報共有サービス（仮称）の構築、電子処方箋の普及、標準型電子カルテの提供といった一連の施策を掲げており、これらの情報連携基盤の中核規格としてFHIRを採用しています。SS-MIX2が「院内データの標準ストレージ仕様」として機能する一方、FHIRは「医療機関間・サービス間でデータをやり取りするためのAPI規格」として位置付けられている点が、両者の役割分担として整理できます。

JP Core（FHIR日本実装ガイド）の現状

FHIRは国際規格であるため、各国の医療制度・コード体系・運用慣行に合わせた実装ガイド（Implementation Guide：IG）を別途策定する必要があります。日本では一般社団法人日本医療情報学会が中心となり、HL7 FHIR JP Core実装ガイドが策定されています。JP Coreは、患者・診療所・医薬品・検査結果といった主要リソースについて、日本の医療制度（健康保険制度・診療報酬・JLAC10/11・YJコード・HOTコード等）に対応する形でプロファイル（制約・拡張）を定義しています。

JP Coreは厚生労働省の標準規格として位置付けられており、電子カルテ情報共有サービス（仮称）や電子処方箋といった全国レベルの情報連携サービスはJP Coreに準拠したFHIRリソースを用いる設計になっています。したがって、SaaSベンダーが「FHIR対応」と表記していても、その対応がJP Core準拠であるか、純粋なHL7 FHIR R4のみの対応に留まるかは、選定段階で確認が必要な要点です。

• JP Core準拠の意味：日本の保険診療コード・医薬品コード・検査項目コード等にマッピングされたFHIRリソースを生成・受信できる
• 純粋HL7 FHIR R4のみの場合：国際標準リソースは扱えるが、日本固有のコード体系への対応は別途実装が必要となる場合がある
• 確認方法：ベンダー資料に「JP Core v○.○準拠」「電子カルテ情報共有サービス接続実績あり」等の記載があるかを確認
• JP Coreは更新が継続される：実装ガイドのバージョンと医療機関側の運用バージョンの整合性確認が必要

厚生労働省・社会保険診療報酬支払基金・各種審議会の公開資料では、JP CoreをベースとしたFHIRリソースの標準化が継続的に進められており、特に「6情報」「3文書」と呼ばれる電子カルテ情報共有サービスの対象データ範囲については、規格・コード・実装ガイドが順次整理されています。

電子カルテ情報共有サービス（仮称）への接続

電子カルテ情報共有サービス（仮称）は、厚生労働省が「医療DXの推進に関する工程表」で示している全国医療情報プラットフォームの中核機能の一つで、医療機関間で患者の診療情報を共有可能にする仕組みです。患者本人の同意のもと、別の医療機関で記録された傷病名・処方・検査結果等を参照できるようにすることで、重複検査・重複処方の削減、救急搬送時の迅速な情報把握、在宅医療・地域連携の効率化等が期待されています。

共有対象とされているのは、いわゆる「6情報」（傷病名・アレルギー情報・感染症情報・薬剤禁忌情報・検査情報（救急・生活習慣病）・処方情報）と「3文書」（診療情報提供書・退院時サマリー・健診結果報告書）です。これらの情報はJP Core準拠のFHIRリソースとして表現され、医療機関の電子カルテシステムから所定のAPI経由でサービスに送信・取得される設計になっています。

• 6情報：傷病名／アレルギー情報／感染症情報／薬剤禁忌情報／検査情報／処方情報
• 3文書：診療情報提供書／退院時サマリー／健診結果報告書
• 接続要件：JP Core準拠のFHIRリソース生成・送受信機能、医療機関等向け総合ポータルサイト経由の認証、患者同意管理機能
• 導入支援：医療情報化支援基金等の補助制度が対象要件を満たす場合に活用可能

SaaS選定の観点では、「電子カルテ情報共有サービス接続実績の有無」「6情報・3文書のFHIR出力可否」「同意管理機能の実装範囲」を確認することが重要です。サービスの正式名称・接続要件・対象施設範囲・開始時期は段階的に整理されていくため、最新の公式情報を確認してください。

SS-MIX2との関係と移行

SS-MIX2（Standardized Structured Medical Information eXchange Version 2）は、厚生労働省が推進する医療情報交換の標準的なストレージ仕様で、HL7 v2をベースとしたメッセージ形式と所定のファイルシステム階層を組み合わせた構造を持ちます。多くの病院・大規模医療機関で災害時のデータ保全、地域医療連携ネットワーク、退院サマリ等の標準化に活用されてきました。

SS-MIX2とFHIRは「置き換えの関係」ではなく「役割分担」と理解するのが実態に近いです。SS-MIX2は院内・地域でのデータ保管・蓄積に強みがあり、FHIRはWeb APIを介したリアルタイム連携・サービス間連携に強みがあります。厚生労働省の各種審議会資料でも、当面は両規格が並存する前提で、FHIRリソースとSS-MIX2の項目をマッピングし、相互変換できる仕組みを整える方向性が示されています。

• SS-MIX2の役割：院内データ標準ストレージ／災害時のデータ保全／地域医療連携
• FHIRの役割：医療機関間・サービス間のAPI連携／電子カルテ情報共有サービス／電子処方箋
• 並存の前提：既存SS-MIX2資産を活かしつつFHIRを段階導入する設計が主流
• マッピングの観点：傷病名・処方・検査結果等は両規格でコード体系を揃える必要

すでにSS-MIX2に対応した電子カルテを運用している医療機関では、ベンダーがSS-MIX2出力に加えてFHIRリソース出力機能を追加実装するロードマップを示しているかを確認することが現実的な対応となります。新規導入の場合は、FHIR対応とSS-MIX2対応の両方を備えた製品を選ぶ、あるいはFHIR対応を主軸としてSS-MIX2出力をオプション機能として扱う製品を選ぶ、といった判断軸が考えられます。

主要電子カルテベンダーのFHIR対応状況の見方

主要電子カルテベンダーはほぼ全社が「FHIR対応」を掲げていますが、対応の中身は製品ごとに大きく異なります。表面的な「対応／非対応」のチェックボックスではなく、以下の観点で深掘り確認することが選定精度を上げる鍵となります。

• FHIRバージョン：R4対応か／R5対応も視野にあるか
• JP Core準拠の有無とバージョン：v1.x／v2.x等、どの版に準拠しているか
• 対応リソース範囲：Patient／Encounter／Observation／MedicationRequest／Condition／AllergyIntolerance／DiagnosticReport等のうち、どこまで生成・受信可能か
• API公開範囲：FHIRリソースを外部システムから取得・更新するためのAPIエンドポイントが公開されているか
• 認証方式：SMART on FHIR（OAuth 2.0ベース）対応の有無
• 電子カルテ情報共有サービス接続実績：実際に接続・運用実績があるか
• 電子処方箋対応：管理サービスとの接続実装が完了しているか
• 追加開発費用の扱い：FHIR連携機能が標準搭載か別費用か、外部システム接続ごとの個別開発費が発生するか

選定時のヒアリングでは、「貴社の製品はFHIR対応していますか？」という質問だけでは不十分です。「JP Core v○.○に準拠していますか？」「Patient・Observation・MedicationRequest等の○○リソースをFHIR R4形式で出力・取得できますか？」「他社SaaSとの連携実績はありますか？」「電子カルテ情報共有サービスへの接続予定はありますか？」といった具体的な質問に落とし込むことで、ベンダーの実装深度を測ることができます。

SaaS選定時の比較観点

電子カルテ本体だけでなく、予約・問診・オンライン診療・PHR・地域連携・調剤連携・経営分析等の医療SaaSを選定する際にも、FHIR連携の観点は重要です。各SaaSがFHIRリソースをどのように扱うかによって、将来的なシステム統合・データ移行・サービス追加の自由度が大きく変わるためです。

• データ入力の標準化：FHIRリソース形式でデータを蓄積する設計か、独自スキーマで蓄積する設計か
• データ出力の自由度：医療機関側がいつでもFHIRリソース形式でデータを取り出せるか（データポータビリティ）
• サービス間連携：他のSaaSとFHIR API経由でデータ連携できるか／個別ベンダー間連携契約が必要か
• カスタマイズ範囲：FHIR拡張リソースを自院の独自項目に対応させる柔軟性があるか
• 監査ログ：FHIRリソースの参照・更新履歴を追跡できるか（AuditEventリソース対応）
• コスト構造：FHIR連携機能が月額利用料に含まれるか／個別オプション費か／連携先ごとの追加開発費か

特に「データポータビリティ」は、SaaSベンダーの乗り換え自由度を左右する重要な観点です。FHIR形式での全データエクスポートが標準機能として提供されている製品は、将来的な乗り換えコストを抑えられる構造になっています。独自フォーマットでしかデータを保管しない製品は、長期的にベンダーロックインのリスクを抱える可能性があります。

認証・同意・セキュリティ要件

FHIRを用いた医療情報連携では、認証・認可・同意管理・暗号化が技術的・制度的に重要な要素となります。厚生労働省「医療情報システムの安全管理に関するガイドライン」、経済産業省・総務省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」（いわゆる3省2ガイドライン）が遵守事項を整理しており、SaaSベンダーはこれらへの準拠が前提となります。

• SMART on FHIR：OAuth 2.0／OpenID Connectをベースとした、FHIRリソースアクセスのための認証認可フレームワーク
• 患者同意管理：電子カルテ情報共有サービスでは、情報共有について患者本人の同意が前提
• 監査ログ：AuditEventリソースで参照・更新・削除の履歴を保管
• 暗号化：通信経路の暗号化（TLS）と保管データの暗号化
• HPKIまたはマイナンバーカード：医療従事者・患者の本人確認手段としての利用
• 3省2ガイドライン準拠：医療情報を取り扱う情報システム・サービスの安全管理基準

SaaS選定時には、「SMART on FHIR対応の有無」「3省2ガイドライン準拠の宣言と第三者監査の有無（ISMAP/ISO 27017/ISO 27018等）」「監査ログの保管期間と参照手順」「インシデント対応プロセス」を確認することが望ましい項目です。これらは医療情報を取り扱う以上、選定担当者が技術詳細を把握していなくとも、ベンダー資料・契約書類で確認できる項目として整理されています。

自己解析チェックリスト（10項目）

自院が医療SaaSのFHIR連携要件をどこまで詰めて確認すべきか、以下10項目で整理してください。「該当する」項目が多いほど、FHIR対応の深さ・JP Core準拠・電子カルテ情報共有サービス接続実績を厳密に確認する必要性が高まります。

• 1. 電子カルテ情報共有サービスへの接続を将来的に検討している
• 2. 電子処方箋の運用を開始済み、または今後開始予定
• 3. 地域医療連携ネットワークに参加している／参加予定
• 4. 複数の医療SaaS（予約・問診・オンライン診療・PHR等）を電子カルテと連携させたい
• 5. 訪問診療・在宅医療で外部医療機関との情報共有が頻繁にある
• 6. 検査会社・画像診断・調剤薬局との連携をAPI経由で自動化したい
• 7. 将来のSaaS乗り換え時にデータを完全な形で取り出したい（データポータビリティ重視）
• 8. 院内SE・情報システム担当者が技術仕様の確認をリードできる体制がある
• 9. 医療情報化支援基金等の補助金活用を検討している（標準規格準拠が要件）
• 10. 患者本人がPHRアプリ等で自身の医療情報を参照できる仕組みを提供したい

該当が7項目以上の場合は、JP Core準拠・電子カルテ情報共有サービス接続実績・SMART on FHIR対応・データポータビリティの4点を契約前ヒアリングの必須項目として組み込むことが推奨されます。3項目以下の場合は、FHIR対応そのものより、現状業務に即した使い勝手・サポート体制・コストを優先順位として上位に置く判断も合理的です。

FHIR対応を急がない方が良いケース

「FHIR対応」は医療DXの方向性として確実に主流化していますが、すべての医療機関が今すぐ最先端のFHIR対応SaaSへ移行すべきとは限りません。以下のような状況では、現行システムの安定稼働を優先し、FHIR対応はベンダーのロードマップに沿って段階的に取り込む方が現実的です。

• 現行電子カルテのリプレース時期が数年先で、現時点で大きな運用上の不満がない
• 診療科特性上、外部システム連携の必要性が限定的（例：単科クリニックで完結する運用）
• 院内のITリテラシー・SE体制が整っておらず、急な移行で運用リスクが高い
• 電子処方箋・電子カルテ情報共有サービス等の接続義務が現時点で発生していない
• 現行ベンダーがFHIR対応ロードマップを公表しており、現行システム上でのアップデートで対応予定

逆に、新規開業・電子カルテリプレース・分院展開・地域医療連携ネットワーク参加といった節目のタイミングでは、FHIR対応・JP Core準拠・電子カルテ情報共有サービス接続実績を選定要件に組み込むことが、中長期の運用コストとデータ可搬性を改善する近道となります。

よくある質問（FAQ）

Q1. 「FHIR対応」を掲げる電子カルテなら、どの製品でも電子カルテ情報共有サービスに接続できますか？
A. 一概にそうとは言えません。電子カルテ情報共有サービスへの接続にはJP Core準拠のFHIRリソース生成、医療機関等向け総合ポータルサイト経由の認証、患者同意管理機能等、複数の要件があります。「FHIR対応」と表記されていてもこれらすべてを満たしているとは限らないため、選定段階で「接続実績の有無」「対応予定時期」を個別に確認することが推奨されます。

Q2. JP CoreとHL7 FHIR R4は何が違いますか？
A. HL7 FHIR R4は国際標準のベース規格で、JP Coreはそれを日本の医療制度・コード体系（健康保険制度・JLAC10/11・YJコード等）に合わせて拡張・制約した日本実装ガイドです。日本国内で電子カルテ情報共有サービスや電子処方箋等の公的サービスに接続するには、HL7 FHIR R4の知識だけでなくJP Coreへの準拠が必要となります。

Q3. SS-MIX2に対応していれば、FHIR対応は不要ですか？
A. 用途によります。災害時のデータ保全・院内データ標準ストレージとしてはSS-MIX2が引き続き機能します。一方、電子カルテ情報共有サービス・電子処方箋・他SaaSとのAPI連携といった用途ではFHIRが採用されているため、外部サービスとの連携を視野に入れる場合はFHIR対応も並行して必要です。両規格は当面並存する前提で整理されています。

Q4. SMART on FHIRとは何ですか？
A. FHIRリソースへのアクセスをOAuth 2.0／OpenID Connectをベースに認証・認可する標準フレームワークです。医療従事者・患者・連携アプリそれぞれに対して、どのリソース範囲を読み書きできるかを細かく制御できる設計になっており、3省2ガイドラインに準拠したセキュリティ運用と親和性が高いとされています。

Q5. FHIR対応のSaaSなら、ベンダー乗り換え時にデータを丸ごと移行できますか？
A. FHIR対応であってもベンダーによってデータエクスポート機能の範囲が異なります。「FHIRリソース形式での全データエクスポート機能の有無」「エクスポート対象範囲（過去○年分など）」「エクスポートに要する作業期間と費用」を契約段階で確認することが、データポータビリティを担保する上で重要です。FHIR対応というだけでは自動的に移行容易性が保証されるわけではない点に注意が必要です。

Q6. 中小規模のクリニックでもFHIR対応は必要ですか？
A. 規模より「外部連携の必要性」と「将来計画」で判断するのが実用的です。電子処方箋を運用予定／地域医療連携ネットワークに参加予定／複数SaaS連携を進めたい場合は、規模を問わずFHIR対応の優先度が上がります。逆に外部連携の予定がほぼなく、単科クリニックで完結する運用なら、現行システムの使い勝手・サポート体制を優先する判断も合理的です。

出典・参考資料

• 厚生労働省「医療DXの推進に関する工程表」 https://www.mhlw.go.jp/stf/newpage_33235.html
• 厚生労働省「医療DX」総合ページ https://www.mhlw.go.jp/stf/iryou_dx.html
• 厚生労働省「電子処方箋」 https://www.mhlw.go.jp/stf/denshishohousen.html
• 厚生労働省「医療情報システムの安全管理に関するガイドライン」 https://www.mhlw.go.jp/stf/shingi/0000516275.html
• 厚生労働省「医療情報化支援基金」 https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000186883_00001.html
• 厚生労働省「標準規格・データヘルス改革」 https://www.mhlw.go.jp/stf/shingi/other-isei_154704.html
• 厚生労働省「電子カルテ情報共有サービスについて」 https://www.mhlw.go.jp/stf/newpage_36079.html
• 経済産業省・総務省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」 https://www.meti.go.jp/policy/mono_info_service/healthcare/iryou/johoka.html
• HL7 International「FHIR Overview」 https://www.hl7.org/fhir/
• 一般社団法人日本医療情報学会「HL7 FHIR JP Core実装ガイド」 https://jpfhir.jp/fhir/core/
• 独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威」 https://www.ipa.go.jp/security/10threats/index.html

本記事は公開情報の整理を目的としており、特定ベンダー・特定製品を推奨するものではありません。導入判断にあたっては、複数ベンダーの公式情報・公的機関の最新発表をご確認のうえ、自院の状況に応じてご判断ください。

関連記事（mitoru編集部おすすめ）

• 電子カルテ SS-MIX2連携完全ガイド
• 電子処方箋導入完全ガイド
• 電子カルテ比較完全ガイド