画像とITの医療情報ポータルサイト

2025-3-17

HL7 FHIRの概要

電子カルテ情報共有サービスが，計画では2025年4月より順次運用を開始する^1）。
中核技術はHL7 FHIR（Fast Healthcare Interoperability Resources）だ。FHIRは，テキスト系医療情報の相互運用性確保に向けた国際標準規格を整備するHL7 Internationalによって2012年ごろに整備がスタートされた。ちょうど米国では，HITEC法（Health Information Technology for Economic and Clinical Health Act）によるインセンティブプログラム“Meaningful Use”の下，医療機関間での標準規格を用いた医療情報共有網の整備が進んでいた。しかし，そこで明らかになったのは，現在整備中の標準規格では「実装作業が重すぎる」ことであった。誰もが簡単に実装できるAPI（Application Programming Interface）形式で提供され，通信手順もREST（REpresentation State Transfer）のような一般的なウェブ通信技術を採用した新しい規格が求められた。FHIRはまさにそのニーズを体現し生まれた技術と言える。
FHIRは大きく2つのコンセプトを持っている。1つが「REST」を採用したという点。医療情報の通信であっても一般的なブラウザで使われるHTTPを用いて，特殊な実装をせず検索や共有ができる。HL7は医療情報共有時のフォーマット（データ形式）の標準規格団体であり，通信要件の定義をしてこなかったが，REST/JSONを通信の基礎と踏み込んだ。そして，もう1つが「リソース」の単位で情報構造を定義した点。一世代前のV3は医療情報の構造化を突き詰めた結果，その定義が壮大になり，非実用的な規格になってしまった。その反省から，小規模な情報の単位「リソース」を規定して最低限の相互運用性を担保し，これらを使うシーンに合わせて自由に組み合わせる定義ができるようにした。

HL7 FHIRの課題

時代に合わせた素晴らしい国際標準規格が誕生したかのように見えるが，実際はそんなに甘くはない。米国や欧州では，このFHIRは確かに注目され，この2つのコンセプトをより生かせるブラウザやモバイル端末を利用したアプリケーション，サービスでの実装が進みつつある。しかしながら，本丸である診療情報や各種レポート情報の情報交換については，2024年末時点でFHIRでの実装はほとんどされていない。すでにHL7 CDA（Clinical Document Architecture）によるコンテンツと，IHE（Integrating the Healthcare Enterprise）地域連携プロファイルを活用した相互運用性の高い情報共有網を整備していたからである。FHIRはRESTを採用したが故に，インターネット上でのセキュリティ確保については実装者が自ら担保する必要がある。また， コンテンツ表現の自由度が高まるのは良いが，それだけ個別要件が多く盛り込まれ，「相互運用性」の実現性が低下することにもつながる。

電子カルテ情報共有サービスのためのHL7 FHIR実装に向けた取り組み

一方，日本では地域レベルでも，診療情報共有をCDAやIHEといった国際標準を用いて整備している事例がほとんどない。それにも関わらず，電子カルテ情報共有サービスでは一足飛びにFHIRを使い，全国の医療施設間での3文書6情報の共有を目指しているわけだ。無論，これを成功させるためには相応の「注意と準備」が必要だ。
まず，通信上のセキュリティ確保についてだが，既存のオンライン資格確認ネットワークを用いることで担保している。すなわち独自のセキュア通信を使い，FHIRのコンセプトであるRESTを使っていない。だが，国家レベルで診療情報交換の通信セキュリティ基盤を，しかも短期間で確保することを踏まえると，最良の選択だったと筆者は考える。サービスの第一の目的は患者さんの診療に資する特定施設間の情報共有にある。RESTの本領が発揮される，不特定施設間の情報共有は，通信インフラも含めて改めて検討をしてもよい。
そして，「リソース」にて共有される情報の相互運用性をいかに担保するか。FHIRは自由度が高い，言わば「緩慢な」標準規格であるため，使う側が使うときの「ルール（規則）」を厳格に決めねばならない。FHIRは「プロファイル」機能でこのルールを定義する。このプロファイル定義を集約した情報をIG（Implementation Guide）と呼び，ウェブコンテンツとして読めるようにもなっている。
各国では，FHIRを活用する際に極めて基礎的な実装要件をプロファイル定義した「○○_Core」と呼ばれるIGを整備している。例えば米国ならUS_Coreとなる。日本では日本医療情報学会のNeXEHRS課題研究会が設置するFHIR日本実装検討WGにて，国内向けのJP_Coreの整備，公開を行っている^2）。現在最新版はVer.1.1.2であるが，2025年1月時点で次期バージョンのVer.1.2.0-aがパブリックコメント中となっている。この中では，例えば日本人の氏名表記（漢字，かな，アルファベットの3種類）や診療情報，各種検査結果，処方情報などの標準的な表現方法，そこで用いる国内での共通用語集が定義されている。だが，あくまで基礎的な実装要件しか定義されていないため，日本でFHIRを用いる際の言わば「最初の一歩」で実装する定義，と考えたい。
例えば，電子カルテ情報共有サービスの3文書6情報の実装要件はどうすればよいのか。このうち2文書5情報の実装要件定義は，JP_CLINS（CLinical INformation Sharing）IGにて別途定義されている^3）。表現したい情報のどの情報箇所をどのFHIRリソースで実装し組み合わせるか，そのリソース内では，JP_Coreを基礎にどのような追加要件定義があるかをこのIGで定義している。図1のように，IGはいくつかの実装「レベル」に分けて整備がなされる。
ではこれらFHIRコンテンツは，院内の業務フローの中でどのタイミングで情報を固め，どう電子カルテ情報共有サービスに送信するのか？　患者さんの紹介を受けた病院では，いつ2文書（診療情報提供書と退院時サマリー）をサービスから取得し，どう端末に展開するのか？　これらは厚生労働省から発行されている「電子カルテ情報共有サービス導入に関するシステムベンダ向け技術解説書（令和6年11月1.2.0版）」に記載がある^4）。いわば，病院運用も含めた外部要件定義書とも言える。システム実装に関する記述もさることながら，重要なのは，医療者がしなければならない運用手順についての記述である。例えば3.2章内の「機能7：同意取得情報の付与」では，サービスの利用同意や情報開示範囲の指定が必須で，このための同意文書の準備や結果情報の登録といった運用の追加も考えねばならない。

図1　FHIRでの実装要件整備

相互運用性の確保のために重要な「プロジェクタソン」

相互運用性の確保で最も重要なことは，これら追加分も含めた「一連の運用の検証」を行い，品質の担保を常に行うことである。特に，このサービスはさまざまな運用パターンの病院に導入された不特定多数の製品が五月雨式に参加するため，個別製品の通信機能の検証だけでは思わぬ障害を招く可能性がある。近年，IHEは国家レベルでの診療情報共有プロジェクトの要件に合わせ，参入ベンダを集めてその実装検証を行う「プロジェクタソン」を開催。特に，欧州ではEHDS（European Health Data Space）整備が打ち出され，各国での医療情報共有基盤の整備に際して，プロジェクタソン検証が行われている^5）。日本の電子カルテ情報共有サービスはIHEの手順こそ使っていないが，国家レベルでの診療情報インフラを本格的に構築する重要な場面である。一足飛びにFHIRを活用するならば，IHEでの基盤実装経験のある欧米以上に注意と準備が求められる。「プロジェクタソン」の活用はその一案である。

^{●参考文献
1）厚生労働省 : 電子カルテ情報共有サービス.
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/kenkou_iryou/iryou/johoka/denkarukyouyuu.html
２）NeXEHRS FHIR日本実装検討WG : JP_Core.
https://jpfhir.jp/fhir/core/
3）HL7 FHIR日本実装検討WG : JP_CLINS（令和２年度厚⽣労働科学特別研究事業「診療情報提供書，電⼦処⽅箋等の電⼦化医療⽂書の相互運⽤性確保のための標準規格の開発研究」他）.
https://jpfhir.jp/fhir/clins/igv1/
4）厚生労働省 : 電子カルテ情報共有サービス導入に関するシステムベンダ向け技術解説書（令和6年11月1.2.0版）.
https://www.mhlw.go.jp/content/10800000/001330543.pdf
5）IHE Europe : Projectathon.
https://www.ihe-europe.net/testing-IHE/projectathons}