医療DX推進体制整備加算の運用開始や、厚労省の「電子カルテ情報共有サービス」立ち上げに伴い、「FHIR（ファイア）」という単語をベンダー資料や厚労省文書で目にする機会が急に増えました。
「FHIR対応です」と説明されても、それが実務にどう効いてくるのかは、電子カルテ更新の経験がない情報システム担当者にはイメージがつきにくい領域です。実装レベルではどんなデータ形式なのか、既存のSS-MIX2との関係はどうなるのか、加算算定にどう関わるのか——このあたりが現場で混乱しやすい論点です。
本記事では、FHIRの技術的な位置づけから、日本での運用実態（JP Core、電子カルテ情報共有サービス）、そして医療機関側で判断が求められるポイントまでを、システム担当者・事務長・院長向けに整理します。
FHIRの基本仕様
FHIR（Fast Healthcare Interoperability Resources）は、医療情報を相互運用するために策定された国際標準規格です。策定団体はHL7 International（非営利の医療情報標準化団体）で、2014年のドラフト版公開を経て、Release 4が2019年、Release 5が2023年に正式版として公開されています。
技術的な特徴を一言でまとめると、「Webエンジニアが扱える医療データ規格」という点に集約されます。従来のHL7 v2やCDAとは異なり、JSON・XML・RDFといった一般的なデータ形式で表現され、RESTful APIで送受信します。これは医療業界外の技術者が参入しやすい構造を意味しており、周辺サービスの開発サイクルを引き下げる要因になっています。
主な技術仕様
FHIRの仕様サマリを整理すると次のようになります。
| 項目 | 内容 |
|---|---|
| 策定団体 | HL7 International |
| 初版公開 | 2014年（ドラフト版） |
| 現行版 | Release 4（2019年）／Release 5（2023年） |
| データ形式 | JSON／XML／RDF |
| 通信方式 | RESTful API（HTTPベース） |
| リソース種類 | Patient・Observation・Condition ほか約150種類 |
| プロファイル | 国・地域ごとに拡張可能（日本は「JP Core」） |
| ライセンス | 無償・オープン |
RESTful APIによる送受信という設計上、Webの一般的なミドルウェア・認証基盤・監査ログ機構がそのまま流用できる点も、実装コストを引き下げる方向に効いてきます。
リソースという概念
FHIRの中核概念が「リソース」です。医療情報を「Patient（患者）」「Observation（検査値・バイタル）」「Condition（診断）」といった構造化された単位に分割し、それぞれをJSONオブジェクトとして表現します。
代表的なリソースを整理すると下表の通りです。
| リソース | 用途 | 主なフィールド |
|---|---|---|
| Patient | 患者情報 | 氏名・生年月日・性別・住所・保険情報 |
| Observation | 検査値・バイタル | 検査項目・値・単位・測定日時 |
| Condition | 病名・診断 | 疾患名・診断日・重症度 |
| Medication | 薬剤情報 | 薬剤名・用法用量・処方期間 |
| AllergyIntolerance | アレルギー情報 | アレルゲン・反応・重症度 |
| Encounter | 受診・入院情報 | 来院日時・診療科・主担当医 |
| Procedure | 処置・手術情報 | 処置名・実施日・術者 |
| DocumentReference | 文書参照 | 紹介状・退院サマリなど |
リソース単位で構造化されているため、必要な情報だけを取り出して他システムに渡す、あるいは複数のリソースを組み合わせて紹介状のような複合文書を生成する、といった柔軟な運用が可能になります。
従来の医療データ規格との違い
FHIRの位置づけを理解するには、既存のHL7 v2、CDA、SS-MIX2との違いを整理する必要があります。
| 項目 | HL7 v2 | HL7 v3／CDA | FHIR |
|---|---|---|---|
| 登場時期 | 1980年代 | 2000年代 | 2014年以降 |
| データ形式 | パイプ区切りテキスト | 複雑なXML | JSON／XML／RDF |
| 実装難易度 | 独自パーサが必要 | 非常に高い | Web標準技術で対応可 |
| 柔軟性 | 低い | 中程度 | リソース組み合わせで高い |
| Web API対応 | 部分的 | 限定的 | ネイティブ対応 |
| PHR連携 | 困難 | 困難 | 容易 |
| 学習コスト | 高い | 非常に高い | 低い |
現状は既存規格との併存が続いており、SS-MIX2で蓄積された過去データがすぐに消えるわけではありません。ただし厚労省のロードマップでは、電子カルテ情報共有サービスをFHIRベースで整備した上で、既存の標準化コードをFHIRに集約していく方向性が示されています。
なぜ日本で今、FHIRなのか
FHIR自体は10年以上の歴史を持つ規格ですが、日本の医療機関にとって足元の論点として浮上したのは、3つの制度的背景があります。
医療DX推進体制整備加算との接続
2024年の診療報酬改定で新設された医療DX推進体制整備加算は、電子処方箋・電子カルテ情報共有サービスへの対応を要件としています。これらの厚労省側システムは、いずれもFHIRを中核データ仕様として設計されています。
つまり、電子カルテやその周辺システムがFHIRに対応していない場合、算定要件を満たすための連携経路を別途構築する必要が出てきます。加算そのものの金額は限定的でも、要件充足の可否は選定基準として無視できない要素です。
電子カルテ情報共有サービスの運用開始
厚労省の「電子カルテ情報共有サービス」は、全国の医療機関が患者情報を安全に共有するための国のプラットフォームで、2025年1月から段階的に運用が始まっています。データの入出力仕様がFHIR（JP Core）で規定されているため、医療機関がこのサービスに接続するには、電子カルテ側でFHIR形式の入出力ができる必要があります。
現時点では大病院・中核病院が先行し、クリニック規模への拡大は2028年以降のフェーズと位置づけられていますが、規模を問わず「準備段階に入っておくべき時期」に来ている状況です。
PHR・研究利用への展開
FHIRで構造化されたデータは、機械可読な状態で他システムに渡せます。マイナポータル・民間PHRアプリとの連携、匿名化を経た研究データとしての提供、AIの学習データとしての利用まで、二次利用の技術的ハードルを下げる規格でもあります。
FHIR対応で医療機関の業務がどう変わるか
制度対応の話とは別に、FHIR対応が現場業務にもたらす変化を、立場別に整理します。
医療機関の業務変化
| 変化 | 内容 |
|---|---|
| 転記作業の削減 | 検査・画像・処方データの手入力が不要になる領域が広がる |
| 乗換リスクの低下 | 電子カルテ変更時のデータ移行の技術的難度が下がる |
| 連携の標準化 | 紹介状・逆紹介状が標準フォーマットで送受信可能に |
| 監査対応 | ログ形式の統一により、第三者監査への説明が整理しやすい |
とくに転記作業の削減は、初診問診や検査データ連携といった日常業務に直接効いてきます。関連する試算方法は下記記事にまとめています。
患者側の変化
FHIR形式で診療情報が返却されれば、患者は自分のPHRアプリで一元管理でき、他院受診時に持参する、あるいは研究・治験への参加時にデータを提供する、といった選択肢が広がります。マイナポータルとの接続も、この規格を前提に設計が進んでいます。
情報返却の仕組みそのものについては、別記事で詳しく整理しています。
業界全体の変化
新規サービス開発の技術基盤が共通化することで、ヘルスケア領域のスタートアップ・製薬会社・保険会社の参入コストが下がり、結果として医療機関側にサービス選択肢が増えます。RWD（Real World Data）としての利活用が進めば、市販後調査や新薬開発の効率化にもつながる領域です。
JP Coreと国内実装のポイント
FHIR Release 4をベースに、日本独自の仕様として整備されているのが「JP Core」です。策定は一般社団法人HL7協会が担当しており、厚労省の電子カルテ情報共有サービスもこのJP Coreを採用しています。
JP Coreの主要プロファイル
| プロファイル | 内容 |
|---|---|
| JP_Patient | 日本の保険情報・住所表記に対応 |
| JP_Observation_Common | 検査値の単位・コード体系 |
| JP_Condition | 日本の疾患分類コード |
| JP_Medication | 日本の薬剤コード体系 |
| JP_DocumentReference | 紹介状・診療情報提供書 |
日本の保険制度・診療科コード・単位表記に合わせた拡張プロファイルが定義されているため、FHIR対応を掲げるシステムを検討する際は、JP Core準拠かどうかを確認しておくと安全です。国際FHIR仕様のみへの準拠だと、国内制度への接続時に追加調整が発生します。
既存電子カルテとの接続方式
FHIRネイティブではない既存の電子カルテを利用している場合でも、変換アダプタ（電子カルテのDBやSS-MIX2出力からFHIRリソースに変換する中間層）を介した接続で、実質的にFHIR化した運用ができるケースがあります。この変換の網羅性・保守性が、連携品質を左右する部分になります。
選定時に確認したい観点
FHIR対応を掲げるシステムを比較する際に、判断を分ける観点は次のあたりです。
- JP Core準拠か、独自プロファイルか：厚労省サービスとの接続を視野に入れるならJP Core準拠がベース。独自拡張の範囲と、その拡張が国内標準と衝突しないかを確認します。
- 対応リソースの範囲：Patient・Observationだけでなく、Condition・Medication・DocumentReferenceまでカバーしているか。カバーが狭いと、紹介状や薬剤情報の受け渡しで手動作業が残ります。
- 変換アダプタの実績：既存電子カルテとの接続で、実運用実績があるか。契約書レベルで「FHIR対応」と書かれていても、実装フェーズで想定より多くの調整が発生する例があります。
- ログと監査対応：FHIRリソースの入出力ログを、監査対応で説明可能な形で保持しているか。医療情報の性質上、ここが不明瞭なベンダーは避ける方が無難です。
AIBTRUSTの取り組み
ヘルスインタビューは、FHIRを前提に設計された問診・情報連携プラットフォームです。患者の問診回答を電子カルテとFHIR形式で構造化連携し、患者側への情報返却もFHIRベースで実装しています。
情報返却の仕組みは、患者がスマホで診療情報を管理し、他院受診・PHRアプリ・研究提供に活用できる形を目指したもので、電子カルテ情報共有サービスとの整合性を意識した設計になっています。既存電子カルテがFHIRネイティブでない場合も、変換アダプタを介した連携で運用開始できるケースが多いため、環境の前提条件については個別にご相談ください。
また、ヘルスインタビュー独自のダイナミックコンセントとFHIRのデータ構造を組み合わせることで、「誰の・どの情報を・何目的で・いつ誰と共有したか」の記録を、監査対応で説明可能な形で残せる設計にしています。
サービス構成の全体像や電子カルテ連携の実装方式は、ヘルスインタビューのサービスページ 、および FHIR電子カルテ連携ページ にまとめています。
現場で聞かれることの多い質問
Q. 既存の電子カルテがFHIR非対応ですが、導入できますか？
はい。ヘルスインタビューは主要電子カルテとの連携実績があり、既存環境に合わせてFHIRベースでの連携を個別設計できます。FHIR非対応の電子カルテでも、変換アダプタを経由して実質的にFHIRデータ化できるケースが多いため、個別にご相談ください。
Q. FHIR導入の初期費用はどのくらいかかりますか？
ヘルスインタビューは初期費用0円から導入可能です。月額36,000円（税抜）〜のベーシックプランには、FHIR情報返却機能が標準搭載されています。
Q. データのセキュリティは大丈夫ですか？
分散型暗号鍵管理・ブロックチェーン技術（独占的特許保有）により、改ざん不能・複製不能な状態で安全にデータを流通できます。3省2ガイドライン・個人情報保護法にも準拠しています。
Q. FHIR対応の電子カルテ情報共有サービスとは？
厚労省が提供する国のプラットフォームで、2025年1月から運用開始されています。全国の医療機関が必要な患者情報を安全に共有できる仕組みで、FHIRを中核データ仕様としています。
Q. 診療報酬算定への影響はありますか？
FHIR対応により、医療DX推進体制整備加算の要件充足が可能になります。具体的な算定要件適合性は、貴院の状況に合わせて個別にご案内します。
Q. FHIRと他の医療IT規格（SS-MIX2など）は共存できますか？
はい、現状は共存運用が可能です。ただし厚労省のロードマップでは最終的にFHIRへの統合が目標とされており、将来的にはFHIRへの移行が必須となります。
まとめ
FHIRは、これからの医療DXの土台となる国際標準規格です。単なるデータ形式の話ではなく、電子カルテ連携・患者への情報返却・研究利用・新規サービスの基盤まで、医療の情報流通構造そのものを変えていく規格として位置づけられています。
医療機関側の実務観点でまず押さえたいのは、加算・電子カルテ情報共有サービスへの接続の観点で「JP Core準拠のFHIR」が要件となる、という点。そして選定時には、対応リソースの範囲・変換アダプタの実績・監査ログの整備状況まで確認する、という点です。
自院の電子カルテ環境でのFHIR連携可否・実装ステップの具体的な相談は、医療機関向けのお問い合わせ からご連絡ください。