HL7 FHIRとは、30年以上更新され続けている医療情報交換の国際標準規格「HL7標準」の最新バージョンで、Webを介した医療情報のやり取りを実現する規格だ。2022年3月には厚労省が進める電子カルテ標準化の標準規格として採用され、令和4年度の診療報酬改定にも登場したことで一躍話題となった。
この記事では、HL7 FHIRの特徴について簡潔に解説するとともに、最後にSS-MIX2との関係から予想される将来の医療情報共有のあり方についても言及する。
HL7 FHIRとは何か？
HL7 FHIRとは、Web通信を前提としさまざまなメリットを有する、HL7 Internationalによって新たに開発された国際的な医療情報交換の標準規格である。
HL7については下記記事をご覧いただきたい。
healthtech-db.com
FHIRはFast, Healthcare, Interoperability, Resourcesの頭文字
そもそも、FHIR (ファイヤー) という名称はFast, Healthcare, Interoperability, Resourcesの4単語の頭文字をとってつけられたものだ。それぞれ、次のような特徴を表している。
最大の特徴は実装の速さと簡単さ
FHIRには、これらの特徴以外にも、セキュアなオンライン環境を担保できるなど多数の特徴がある。しかし、やはり最大の特徴は実装の速さと簡単さであろう。これを実現できている背景には、次のような理由が挙げられる。
- 実装者が使いやすい人間可読な形式のデータであり、簡潔でわかりやすい仕様となっている。
- HL7 Internationalが無料で仕様を公開しているほか、多くの実装ライブラリ・実例が存在する。
- リソースとAPIを主要な構成要素として定義し、RESTful APIを中核技術として採用している。
このうち特に重要である「リソース」と「RESTful API」について、詳しく見ていこう。
HL7 FHIRの軸となる「RESTful API」「リソース」とは何か？
リソース：交換対象となるあらゆるデータを性質ごとに区切った最小単位
リソースとは、交換対象となるあらゆるコンテンツ・データを、性質をもとに区切り、断片化したものを指す。
例えば、HL7 FHIRでは、以下のような区切り方がある。
- 関係主体（患者、医師、ケアチーム、デバイスなど）
- 記録管理すべき情報（臨床情報、診断情報、薬剤など）
RESTful API：Webサービスの設計モデル「REST」をAPIで実現するもの
RESTはシンプルで柔軟性を備えたWebサービスの設計モデルであり、医療領域であれば「医療データをリソースに区切り、リソースをWeb通信でやりとりする設計」のことを指す。これは REpresentational State Transfer の略であり、直訳すると「具象化された状態の転送」、言い換えれば「具体的に状態を定義した情報のやりとり」となる。
さらに、"RESTful" な情報連携サービスは、以下の条件を満たすとされている。これらについて、従来の連携方法との違いとともに図で説明する。
- HTTPメソッドを利用する
- URIでWebサーバ上のリソースを指定する
- ステートレスである
- XML、JSONを利用する*
* 文献によっては「処理結果がHTTPステータスコードで通知される」になっている。
従来の連携方式との違い
従来の連携方式との違いは図のように示される。
従来の連携方式では、現実世界でやりとりされる文書をデジタルフォーマットで定義することで、ファイル交換やファイル添付のメッセージの手段で電子化を実現していた。そのため、サーバは指定されたファイルや文書全体をクライアントに渡すことになり、用途が決まっている場合は無駄が多くなりやすかった。
また、実装作業は複雑で構築の難易度は高かった。理由としては、クライアント側もサーバ側も用途ごとにAPIを実装し直す必要があったこと、データアクセス先の仕様の確認もテストアプリで行う必要があったことなどが挙げられる。
一方、RESTful APIを用いたHL7 FHIRでは、交換対象となる情報がリソースという形で細分化（モジュール化）されているため、必要な項目のみを指定して取得し、取得した側で加工表示を行うことが可能となった。
また、実装作業は容易になった。理由としては、リソースをさまざまな用途に利用できるため用途別にAPIを実装し直す必要がなくなったこと、データアクセス先の仕様をブラウザ上で確認できるようになったこと、ライブラリ・実例・基本的なフレームなどが充実していることなどが挙げられる。
さらに、この図にも描かれている通り、ブラウザからの利用が可能であることもFHIRの大きな利点だ。PHRアプリを含むスマートフォンやウェアラブルデバイスからの利用も可能で、ヘルステック業界へのインパクトも小さくないと考えられる。
リソースを一意に識別する "住所" の役割を果たす「URI」
RESTful APIでは、PCなどのデバイスは、意図したリソースにアクセスすることで目的の医療データを取得しなければならない。このために使われるのが、各リソースの場所を示す「URI」だ。
「リソース」はどこかの場所に保管されることになるが、その保管場所を便宜上住所と呼ぶことにしよう。この「住所」と「リソース」は1対1で対応しており、住所はリソースを一意に識別できるものとする。このような性質を持つ「住所」が実際に定められており、これをURI (Uniform Resource Identifier) と呼ぶ。
このURIをAPIに投げることにより、APIからデバイスに目的のリソースが返される。
URIの例（仮データなのでアクセスしないでください）
http://hapi.fhir.org/baseDstu9/Patient/3751099/_history/1?_format=json |
▲ baseDstu9の団体に保管されている、患者ID 3751099の病歴に対応するURI。?以降では、取得形式などデータの条件を指定することもできる。
SS-MIX2とHL7 FHIRの関係
最後に、国内で使われてきた標準規格であるSS-MIX2とHL7 FHIRとの関係について述べる。
SS-MIX, あるいはSS-MIX2は、全国の電子カルテ標準化以前に構築されてきた「地域医療連携ネットワーク」の中で使われている規格だ。2010年代の日本国内では、HL7とSS-MIXが併存してきたことが下の年表からも読み取れる。
では、HL7 FHIRが電子カルテ標準化の規格として採用されたいま、即座にSS-MIX2は廃止されるのだろうか？
答えは、おそらくNoだ。
HL7 FHIRとSS-MIX2は規定しているものが違う
廃止されないと考えられる理由は、SS-MIX2の対象範囲はシステムに格納する方法、HL7 FHIRの対象範囲はシステム間で情報をやりとりする方法であり、それぞれ別のものを規定しているためである。
先ほどまで述べてきたように、HL7 FHIRが規定しているのは「RESTful APIの仕組みを用いてリソースという型の医療データを交換する」ということである。これは「システム間で情報をやりとりする方法」に対する規定であり、「データをどう格納するか」についての規定ではない。
一方、SS-MIX2はデータをサーバに格納するための方法（フォルダ構成など）を定めた規格であり、HL7 FHIRとは役割が異なっている。
SS-MIX2が扱ってきたのはHL7 V2.5だが、HL7 FHIRには相互運用性がある
役割は違うとしても、SS-MIX2の方が古くにできているのでHL7 FHIRとうまく連携できないのではないか？という疑問もあるかもしれない。たしかに、SS-MIXやSS-MIX2が主に扱ってきたのはHL7 V2.5のメッセージデータである。しかし、HL7 FHIRは先述の通りInteroperability (相互運用性) を有している。現時点ではまだ課題はあるものの、将来的には互換性が担保されるようになると考えられる。
実際、2022年5月に厚生労働省主催で行われた「医療情報ネットワークの基盤に関するワーキンググループ」の会議でも「役割が違うので、必ずしも置き換わるだけではなくて、それぞれの役割を持って、うまくお互いを補完する形で使われていくのかと思います」といった意見が述べられていた。資料内にも次の図が掲載されており、近いうちにHL7 FHIRとSS-MIX2の接続によって医療情報共有の新しい形が実現する可能性に期待がかかる。
