事例

電子カルテ情報共有サービスへの対応に向けた「HL7 FHIR 仕様」の実装への試み

本セッションは 2024 年 11 月に開催された Claris カンファレンス 2024 のメディカルセッションの内容を取材記事としてまとめた内容です。実際の動画はこちらより視聴いただけます。
演者:株式会社エムシス 代表取締役 秋山 幸久 氏




目次

  1. 医療情報交換の標準規格「FHIR」とは?
  2. FileMaker を利用して FHIR 仕様を実装
  3. FHIR 仕様を理解して JSON でリソースを記述
  4. 自ら FHIR 仕様を実装するには課題も多い

日本政府は医療 DX の一環として、医療機関の間で患者の診療情報を電子的に共有できるようにするため、「電子カルテ情報共有サービス」を 2025 年度中に稼動する計画である。従来、紙の文書・帳票でやり取りしていた患者情報を新たに構築するデータベースに登録し、医療連携先や全国の医療機関で参照できるようにするサービスだ。

電子カルテ情報共有サービスに登録・共有する診療情報は、HL7 FHIRという国際標準規格で行うこととされ、各医療機関は自院の電子カルテなどの医療情報システムの診療情報を同規格に変換する必要がある。今後、各医療機関は既存医療情報システムを改修し、ベンダーが提供する FHIR 変換サーバーなどを用いることになる。その変換のための仕組みを Claris FileMaker を使って構築する方法を、Claris パートナーであるエムシスの代表取締役 秋山幸久氏が Claris カンファレンス 2024(2024 年 11 月開催)で解説した。

1. 医療情報交換の標準規格「FHIR」とは?

2024 年度の診療報酬改定で「医療 DX 推進体制整備加算」という算定項目が新設され、少額ながらも診療報酬請求が可能になった。その施設基準は保険証のオンライン資格確認を行う体制を有していることなどが示されている。そして 2025 年 10 月からは、電子カルテ情報共有サービスを活用できる体制を有していないと算定できなくなる。そのため、各医療機関は DX への対応が求められる。

当面、電子カルテ情報共有サービスでは、「3 文書・6 情報」を共有する計画だ。「3 文書」とは診療情報提供書(いわゆる紹介状)、健康診断結果報告書、キー画像等を含む退院時サマリーで、「6 情報」は傷病名、感染症情報、アレルギー情報、薬剤禁忌情報、検査情報、処方情報である。これらの情報は、電子カルテ情報共有サービスとして構築する文書情報管理データベースとオンライン資格確認等システムのプラットフォーム上に構築する臨床情報管理データベース、健診文書管理データベースに登録していくが、その際に医療情報交換の標準規格である FHIR 形式にする必要がある。

電子カルテ情報共有サービスの概要(出典:厚生労働省資料)

この FHIR とは Fast Healthcare Interoperability Resources の略で、Web 通信(REST API)方式を使用して、可読性が高く取り扱いがしやすい JSON 形式のデータの集合(リソース)をやり取りできるという特徴がある。Web 通信を利用するため、全国の医療機関同士で診療情報を共有できることに加え、患者自身がスマートフォンを使ってマイナポータルで自分の診療情報を閲覧することも可能だ。

電子カルテ情報共有サービスを利用する医療機関は、必須ではないが電子カルテ等医療情報システムのデータを FHIR 形式に変換する FHIR サーバーを導入することになる。その場合、ファサード型またはリポジトリ型を選択することになるという。ファサード型は、クライアント側の電子カルテシステム等のデータを電子カルテ情報共有サービスに登録するタイミングで都度 FHIR 変換する方式。リポジトリ型は、電子カルテ情報共有サービスに登録するタイミングとは関係なく、電子カルテシステム等のデータをあらかじめFHIR変換し、変換したデータをリポジトリにデータとして保存しておく方式だ。それらに対し秋山氏は、「電子カルテなどのリソースから診療情報提供書や退院時サマリーなどをFHIR形式で作成し、そのデータを FileMaker Server に保管しておく仕組みで、FHIR リポジトリが構築されたら、それら FHIR 形式データを送信する」リザーブ型(自称)という方式を提案した。

2. FileMaker を利用して FHIR 仕様を実装

実際に診療情報提供書をFHIR仕様に従いデータ作成する際には、まず医療機関情報や患者情報、傷病名、検査情報などの記載に必要な情報を電子カルテシステムや部門システムから取得し、それらを FHIR 形式に変換して文書情報データとして生成するプロセスが考えられる。秋山氏は実際にFHIR形式の診療情報提供書を作成するために、Claris FileMaker をプラットフォームとした同社が提供する電子カルテシステム「ANNYYS」、ORCA(日医標準レセプトソフト)をデータソースとして各種情報を取得のうえ、FHIR 仕様を実装する方法を解説した。

FileMaker で FHIR 仕様を実装するシステム構造について秋山氏は、「バックヤードで Ubuntu クラウド上に FileMaker Server を構築し、 ANNYYS をはじめ、ANNYYS と連携する ORCA や DWH からデータソースの取得などを行う仕組みを実装しました」と説明。実際に ORCA から医療機関情報や患者情報を、そして ANNYYS の各種情報の記載画面から既往歴やアレルギー情報などを取得し、FileMaker カスタム App で FHIR 仕様の診療情報提供書データを作成するデモを行った。

FileMaker で作成した HL7 FHIR 仕様を実装するカスタム App

カスタム App のインターフェース上には、ANNYYS を起動して患者カルテを開いたときにはすでに自院の医療機関情報や医師の氏名は登録されており、次いで紹介先の医療機関・診療科・担当医師名を入力。カスタム App がデータソースから取得した傷病名やアレルギー、感染症情報などが表示されているのでそこからそれぞれ選択し、紹介先の医師に伝えるべきコメントを入力する。それらの情報は従来の紙の診療情報提供書と同様に PDF 出力もできる。

一方で、診療情報提供書に記載する各情報を登録操作する際、その都度 JSON 形式の FHIR リソースがカスタム App によって作成されていく。それぞれのリソースがまとめられ、最終的に診療情報提供書の FHIR 形式データが完成する。

3. FHIR 仕様を理解して JSON でリソースを記述

こうした FHIR 形式のデータを作成するためには、診療情報提供書や退院時サマリーなどの各 HL7FHIR 記述仕様書および実装ガイドを参照しながら FileMaker のスクリプトを記述していく必要がある。これら記述仕様書などは、日本医療情報学会の NeXEHRS 課題研究会FHIR 日本実装検討ワーキンググループが運営するサイトなどから入手することができる。「実装ガイドには、診療情報提供書に使用されるリソースのさまざまなプロファイルが示されており、各プロファイルの必須要素と推奨要素などの詳細が書かれています。この仕様に従って FHIR データを作成していくことが、アプリで診療情報提供書を実装するときに必要な手順になります。非常に多くの項目があるので、その中から必要な記述様式を見ていかなければならず、最初は多大な労力と時間を要します」(秋山氏)。

FHIR 形式では、医療情報は FHIR リソースと呼ばれる単位で記述される。FHIR リソースには患者情報リソース、医療機関情報リソース、検査結果リソースなど各種情報のリソースがある。これらの FHIR リソースすべてを束ねたものは Bundle リソースと呼ばれ、それが診療情報提供書などの文書リソースということになる。階層的に Bundle リソースの配下に各 FHIR リソースが連なった構造であり、それらの“目次”の役割をする Composition リソースにより患者情報や検査結果といった具体的なリソースにリンクしている。「『診療情報提供書HL7 FHIR記述仕様』の『全体構造』の項を読むと、Bundle リソースの Type 要素の値を document とすることにより、Bundle リソースの 1 つのタイプである FHIR Document を記述できるとあります。Bundle(document)があって次に entry、Composition が記述され、その後に Patient(患者情報)や Practitioner(医師情報)、Organization(医療機関情報)などが連なるということがわかります。これらに則って JSON を記述していく必要があります。JSON のサンプルも掲載されており、それと見比べていくと、実際にそうなっていることがわかります」(秋山氏)。

4. 自ら FHIR 仕様を実装するには課題も多い

秋山氏は、さらに仕様書の読み解き方や注意点を解説したうえで、FHIR 仕様を実装するにあたって見えてきた課題として次のような点を指摘した。まず、リソースデータとなる院内の各種システムからさまざまな情報を取得・連携する仕組みが必要になる。また、医療情報には数多くの多様な情報が存在し、その中にはコード化されていない情報も多い。そのためコード体系、具体的なコードとその定義の整備が必要であること。一方、医療機関により医療情報システムで病院固有のコード(ローカルコード)を使用していることがあり、それらを共通コードへの変換仕様も必要になるという。

今回、秋山氏は自作で FHIR データを作成してみたということだが、FHIR サーバーにアップロードして問題がないかリソースチェックが必要であり、その作業もかなりの労力を要したとのこと。「仕様書を読み解く際に英語での解釈が必要となる場面もまだ多いうえ、注意深い作業が必要だったため相当の時間を要しました」(秋山氏)と述べた。

今回のセッションで参照した各種 URL

  1. HL7®FHIR® 日本実装検討WG
  2. FHIR IGポータル
  3. 電子カルテ情報共有サービス 2 文書 5 情報・患者サマリー FHIR 仕様
  4. 診療情報提供書 - 電子カルテ情報共有サービス 2 文書 5 情報+患者サマリー FHIR 実装ガイド
  5. Artifacts Summary - 電子カルテ情報共有サービス 2 文書 5 情報+患者サマリー(リソースサンプル集)
  6. 診療情報提供書 HL7FHIR 記述仕様(PDF 版)
  7. 日医標準レセプトソフト API 実装仕様