電子カルテの選定資料や医療DXの解説で、「HL7 FHIR（エイチエルセブン・ファイア）対応」という言葉を見かけるようになりました。「対応していると何がよいのか」「対応していないと困るのか」が、言葉からは伝わりにくい用語です。
FHIRは、ひと言でいえば**医療データの「共通の書式」**です。書式が揃うと、システムが違ってもデータをやり取りできるようになります。この「やり取りできる」という性質が、クリニックにとってはデータ移行のしやすさ、他システムとの連携、そして特定ベンダーへの依存の回避に直結します。
本記事では、FHIRとは何か、なぜ必要とされているのか、日本でどう位置づけられているのか、そしてクリニックが確認すべき点を整理します。
免責：本記事は一般的な情報提供です。仕様やサービスの対応状況は変わり得ます。導入検討時は各ベンダーの最新情報および所管ガイドラインの最新版をご確認ください。
FHIRとは何か——医療データの「共通の書式」
HL7 FHIR（Fast Healthcare Interoperability Resources） は、医療情報をシステム間でやり取りするための国際的な標準規格です。医療情報の標準化に取り組む国際団体 HL7 が策定しています。
たとえで説明します。
紹介状を書くとき、病院ごとに「氏名は右上」「生年月日は2行目」「病名は3枚目」と書式がバラバラだったら、受け取る側は毎回読み方を確認しなければなりません。書式が共通なら、どこから来た紹介状でも同じ読み方ができます。
FHIRはこの「共通の書式」を、紙ではなくデータについて定めたものです。「患者の情報はこの形」「処方の情報はこの形」「検査結果はこの形」 と決めておくことで、作ったシステムが違っても、同じ読み方でデータを扱えます。
なぜ必要になったのか——形式がバラバラ問題
医療のシステムは、電子カルテ、レセコン、検査システム、予約システム、画像システムなど多岐にわたります。これらは別々の会社が別々の時期に作っており、データの持ち方が製品ごとに異なります。
その結果、次のような問題が起きます。
- 電子カルテを別製品に切り替えるとき、過去のデータをそのまま移せない
- 検査機器のデータをカルテに取り込むのに、製品の組み合わせごとに個別の対応が必要になる
- 地域の病院とデータを共有したいのに、形式が違って読めない
いずれも根っこは同じで、「同じ内容なのに、形式が違う」 ことが原因です。
この問題への答えとして、書式を先に決めておくのが標準規格の考え方です。共通の書式に対応したシステム同士なら、個別の翻訳作業なしにデータを受け渡せます。この「1対1で個別対応する代わりに、共通規格に合わせる」という発想は、AIの分野で MCP が解こうとしている問題と同じ構造です。
「リソース」という単位で考える
FHIRの特徴は、医療情報を**「リソース」という小さな塊に分けて定義している**点です。
| リソースの例 | 中身 |
|---|---|
| 患者（Patient） | 氏名、生年月日、性別、連絡先など |
| 受診（Encounter） | いつ、どこで、どの診療科を受診したか |
| 病名（Condition） | 診断名、発症日、状態 |
| 処方（MedicationRequest） | 薬剤、用量、用法、処方日 |
| 検査結果（Observation） | 検査項目、値、単位、測定日 |
| アレルギー（AllergyIntolerance） | アレルゲン、反応、重症度 |
紹介状を丸ごと一つの大きな書式にするのではなく、「患者」「病名」「処方」といった部品ごとに書式を決め、それを組み合わせて使うという考え方です。
この設計には実務上の利点があります。「処方情報だけ欲しい」「検査結果だけ連携したい」といった部分的なやり取りが自然にできることです。全部を一度に扱う必要がないため、必要な範囲から段階的に対応を進められます。
Web技術ベースだからAPIと相性がよい
FHIRのもう一つの特徴は、Webサイトやスマートフォンアプリで使われている一般的な技術を土台にしていることです。
過去の医療データ規格は、医療に特化した独自の形式が多く、扱える技術者が限られていました。FHIRは、Webの世界で広く使われているデータ形式と通信方式をそのまま採用しています。そのため、医療専門ではないソフトウェア開発者でも扱いやすく、対応するツールも豊富です。
これは、API との相性の良さにつながります。「患者IDを指定して処方情報を取り出す」「検査結果を登録する」といった操作を、Webの標準的な作法で行えるからです。FHIRとAPIとMCPがそれぞれ何を担うのかは MCPとAPI・FHIRは何が違うのか？ で整理しています。
日本での位置づけ
日本でも、医療情報の標準化にFHIRが用いられる方向で施策が進められています。厚生労働省は、電子カルテ情報の共有に関する標準規格としてFHIRに基づく仕様を採用し、次のような取り組みでその形式が使われています。
- 電子カルテ情報共有サービス：医療機関の間で診療情報を共有する全国的な仕組み。共有する情報の形式にFHIRに基づく仕様が採用されています。詳細は 電子カルテ情報共有サービスとは をご覧ください。
- 標準型電子カルテ：政府が整備を進めている電子カルテの取り組み。標準規格への対応が前提となっています。詳細は 標準型電子カルテとは？ をご覧ください。
- 電子カルテの標準要件：民間の電子カルテ製品にも、標準規格への対応が求められる流れになっています。
つまり、FHIRは「一部の先進的な製品が使う技術」ではなく、国の医療DXの土台となる書式として位置づけられています。制度の詳細や時期は変わり得るため、最新情報は所管省庁の公開資料でご確認ください。
SS-MIX2との違い
日本の医療現場では、以前からSS-MIX2という標準化の仕組みが使われてきました。「FHIRと何が違うのか」と聞かれることが多いので、簡単に整理します。
| 観点 | SS-MIX2 | FHIR |
|---|---|---|
| 主な使い方 | 診療データをまとめて保管・蓄積する | システム間で必要な情報をその都度やり取りする |
| 得意な場面 | バックアップ、データの一括出力 | リアルタイムの連携、アプリからの参照 |
| 技術の土台 | 医療向けの従来形式 | Web技術ベース |
両者は対立するものではなく、役割が違います。SS-MIX2は「倉庫」に近く、FHIRは「窓口」に近いイメージです。当面は併存し、用途に応じて使い分けられると考えられます。データ移行の実務でどちらがどう関わるかは 電子カルテの標準要件に沿ったデータ移行の方法 で扱っています。
クリニックの業務ではどう関わるのか
FHIRを職員が直接操作する場面はありません。しかし、クリニックの選択の自由度に関わる形で、間接的に効いてきます。
① データ移行がしやすくなる 電子カルテを切り替えるとき、標準形式で出力できるデータは、次の製品に取り込みやすくなります。「前のカルテのデータが持ち出せず、切り替えを諦めた」という事態を避けやすくなります。
② 他システムと連携しやすくなる 予約、問診、検査機器、会計など、周辺システムとの連携が、製品ごとの個別対応ではなく共通の作法で行えるようになります。
③ ベンダーロックインを避けやすくなる データが標準形式で扱えるということは、「このベンダーでないとデータを読めない」状態から抜け出せるということです。この論点は 電子カルテのベンダーロックインとは で扱っています。
④ 地域連携・情報共有に対応できる 電子カルテ情報共有サービスのような全国的な仕組みに参加する際、標準規格への対応が前提になります。
医療機関が確認すべき点
「FHIR対応」と書かれていても、中身には幅があります。選定時には次を確認しておくと、実態がつかめます。
① どのリソースに対応しているのか 患者・処方・検査結果など、どの情報を標準形式で扱えるのか。「一部だけ」の場合、自院に必要な情報が含まれるか。
② 出力できるのか、取り込めるのか、両方か 標準形式で外に出せるだけなのか、外から受け取れるのか。移行では「出力」、連携では「双方向」が問われます。
③ 追加費用はかかるのか 標準形式でのデータ出力や連携が、標準機能なのか、オプション費用や個別開発が必要なのか。
④ 国の仕組みへの対応状況 電子カルテ情報共有サービスなど、国の施策への対応が済んでいるか、予定はどうか。
⑤ セキュリティの扱い データをやり取りする以上、通信の保護、アクセス権限、記録（ログ）の考え方が 3省2ガイドライン に沿っているか。
よくある誤解
「FHIR対応なら、どの製品とも自動でつながる」 ——書式が共通でも、実際につなぐには両側の対応と設定が必要です。共通の書式は「つなぎやすくする」ものであって、「勝手につながる」ものではありません。
「FHIR対応は大病院の話」 ——電子カルテ情報共有サービスや標準型電子カルテの動きは、診療所も対象に含んでいます。クリニックにとっても、データの持ち出しやすさに直結する話です。
「対応していれば中身も標準化されている」 ——書式が同じでも、病名や薬剤の「コード（呼び方）」が製品ごとに違えば、読み替えが必要になります。書式と用語の両方が揃って、はじめて実務でつながります。
電子カルテとの関係
FHIRは、電子カルテにとって**「外とつながるための共通の書式」**にあたります。院内のデータをどう持つかは製品ごとに設計されていてよく、外に出すとき・外から受け取るときに共通の形に揃える、という位置づけです。
ここで重要なのは、「院内は一体、院外とは標準規格でつなぐ」 という組み合わせが現実的な形だという点です。記録・算定・文書のように日常業務で密接に関わるデータは一つの基盤で扱い、他の医療機関や国の仕組みとの受け渡しには標準規格を使う。この考え方は 電子カルテでMCPを使うとは？ でも同じ結論に至っています。
ポテックの「AIカルテ」は、設計段階からAIを前提にしたAIネイティブ型で、電子カルテとレセコンを一体で扱う構成をとっています。院内のデータを一つの基盤で扱いつつ、標準規格に基づく外部との連携を重視する設計思想については AIネイティブ電子カルテとはどんなものなのか？ をご覧ください。
まとめ
- HL7 FHIRは、医療データをシステム間でやり取りするための「共通の書式」
- 必要とされた理由は、同じ内容なのにシステムごとに形式が違う問題
- リソースという部品単位で定義されており、必要な情報だけを部分的にやり取りできる
- Web技術ベースのため開発者が扱いやすく、APIと相性がよい
- 日本では電子カルテ情報共有サービスや標準型電子カルテの土台として位置づけられている
- **SS-MIX2は「倉庫」、FHIRは「窓口」**の役割で、併存して使い分けられる
- クリニックにはデータ移行・連携・ベンダーロックイン回避・地域連携の面で効いてくる
- 「FHIR対応」の中身は幅があるため、対応リソース・入出力の方向・費用・国の仕組みへの対応・セキュリティを確認する
AIカルテの詳細やデモのご希望は、お問い合わせください。