`
`

FHIRとは - HL7 v2との違い・JP Coreと電子カルテ連携

FHIR(Fast Healthcare Interoperability Resources)は、HL7 Internationalが策定する医療情報交換の標準仕様である。ファイアと読み、患者情報、検査結果、薬剤情報などを「リソース」という単位で表現する。

HTTPによるWeb APIやJSON・XMLを利用でき、電子カルテとWebアプリケーションの連携、施設間での情報共有などに用いられる。ただし、FHIRは単に医療データをJSONで書くための形式ではない。情報の項目・意味・関係と、それらを交換するための仕組みを定めている。HL7:FHIRの概要

FHIRによる情報連携をご検討の方へ:FHIR連携の開発対応をご覧ください。

リソースとは何か

リソースは、患者、検査依頼、検査結果などを表現するための基本単位である。リソース同士を参照で結び、誰に対する、どの依頼に基づく結果なのかを表す。

リソース主に表す情報利用例
Patient患者の識別・基本情報患者識別子や氏名などを管理する
ServiceRequest検査や処置などの依頼CT検査の依頼を表す
Observation観察・測定結果検査値やバイタル値を表す
DiagnosticReport診断・検査の報告所見と関連する検査結果をまとめる
ImagingStudy画像検査の構成や参照先検査・シリーズ・インスタンスに関する情報を表す

例えば、血液検査の結果を扱う場合、Patientへの参照を持つObservationに測定結果を記録し、DiagnosticReportから関連する結果を参照する構成がある。どのリソースをどう組み合わせるかは、対象業務と実装ガイドに従って決める。Patient、ServiceRequest、Observation、DiagnosticReport

Web APIではどう利用するか

REST APIを利用する構成では、クライアントがFHIRサーバに対してリソースの参照や検索、登録・更新などを要求する。例えば、権限のあるアプリが患者に関連する検査結果を検索し、取得した結果を画面に表示する使い方がある。

すべてのFHIRサーバが、すべてのリソースや操作に対応しているわけではない。接続時には、CapabilityStatementなどで対応するリソース、検索条件、操作を確認する。また、FHIRにはREST以外に文書・メッセージによる交換方式もあり、採用方式を接続先と揃える必要がある。FHIR RESTful API

HL7 v2・SS-MIX2との違い

HL7 v2は、患者登録や検査結果の通知などをメッセージで伝える規格である。FHIRとの関係は、既存システムをすべて置き換えるというものではなく、必要な情報を変換・連携して併用することもできる。HL7 v2とFHIRの比較

SS-MIX2は、医療情報を所定の構造で蓄積するストレージの仕様などを定める仕組みであり、FHIRと同じものではない。標準化ストレージではHL7 v2.5形式の情報を扱い、拡張ストレージではそれ以外の形式の情報も扱う。日本医療情報学会:SS-MIX2仕様書・ガイドライン

例えば、SS-MIX2に蓄積された情報をアプリケーションで活用するためにFHIRリソースへ変換する構成は考えられる。ただし、ストレージがあるだけでFHIR APIが提供されるわけではない。対象データの抽出、コード・単位の対応、更新履歴の扱いなどを別途設計する。

JP Coreと実装ガイド

JP Coreは、日本でFHIRを利用するための共通的なルールを定めた実装ガイドである。FHIRの基本仕様に対して、項目の制約、使用するコード、拡張などを整理している。JP Coreだけですべての個別業務の接続仕様が決まるわけではなく、サービスや用途ごとの実装ガイドも確認する。

2026年9月11日の確認時点で、JP Coreの公開履歴では1.2.0が現行公開版として掲載され、基盤となるFHIRの版はR4(4.0.1)である。別に電子カルテ情報共有サービス用の1.1.2-clinsや、開発版の掲載もある。実装では、名前や「latest」というURLだけで判断せず、接続対象が指定する版を確認する。JP Core公開履歴、JP Core 1.2.0

電子カルテ情報共有サービスでの利用

国内の具体例には、医療機関や薬局などで電子カルテ情報を共有する「電子カルテ情報共有サービス」がある。ベンダー向けに技術解説書やFHIRに関する実装資料が公開されており、FHIRを実際の国内サービスの仕様と結びつけて理解できる。

対応を検討する際は、共有する情報、対象となる文書・リソース、コード、登録・更新の条件を、当該サービスの資料で確認する。FHIRやJP Coreに対応していることだけで、サービスへの接続要件をすべて満たすわけではない。厚生労働省:電子カルテ情報共有サービス

DICOMwebと組み合わせる画像情報連携

医療情報を扱うHL7ファミリーの中にHL7 v2とFHIRを配置し、画像連携のDICOM・DICOMwebとの役割を比較した図
図:FHIRとDICOMwebは、それぞれの役割に応じて組み合わせることができる。図ではFHIRのWeb API利用を取り上げているが、文書・メッセージによる交換方式もある。DICOMwebはDICOM規格に含まれるWebサービスである。 図を拡大して見る

FHIRのImagingStudyは、画像検査の構成や画像にアクセスするための参照先などを表すリソースであり、画像のピクセルデータそのものを格納するものではない。例えば、FHIRで検査情報を共有し、画像本体をDICOMwebで取得する構成が考えられる。FHIR:ImagingStudy

この場合、FHIR側とDICOM側で患者・検査の識別を対応づけ、両方のアクセス権限を設計する必要がある。FHIRを採用しても認証・認可が自動で完成するわけではない。誰がどの情報を参照できるか、アクセスをどう記録するかまで検討する。FHIR:Security

FHIR連携の開発について

既存の院内システムとWebアプリケーションの接続や、HL7 v2からFHIRへの情報連携についてご相談いただけます。リベルワークスでは、FHIRやJP Core、電子カルテ情報共有サービスに関連する実装に対応しています。

関連するナレッジ