FHIRで紹介状を書くと、こうなる【電子カルテ情報共有サービスとMed-Well 第4回目】

はじめに

こんにちは！総合病院向けのLINE窓口システム「Med-Well（メドウェル）」を提供するコモン・クリエーションです。

本記事は「電子カルテ情報共有サービスとMed-Well」シリーズの第4回目です。

シリーズ「電子カルテ情報共有サービスとMed-Well」

• 「電子カルテ情報共有サービス」って何だろう？

• 電子カルテ情報共有サービスには、どうやって繋ぐ？

• 電子カルテ情報共有サービスのIF定義書を読んでみる — 診療情報提供書はどんな形？

• FHIRで紹介状を書くと、こうなる  ◀ 今見ている記事

• 電子カルテ情報共有サービスに繋ぐまでの道のり — ベンダー登録と接続テストの話

前回までで、電子カルテ情報共有サービスのデータが「FHIR Document（Bundle）」という多段の入れ子構造になっていること、そしてそのなかに診療情報提供書や退院時サマリーなどの文書情報が入っていることを見てきました。

今回はその一段下の世界、つまり「FHIR Documentの中身そのもの」に踏み込みます。題材として使うのは、紹介状にあたる診療情報提供書（eReferral）です。エンジニア寄りの内容になりますが、できるだけ「紙の紹介状に書いてある各項目が、FHIRではどこに入るのか」という切り口で、わかりやすく整理していきます。

参照する仕様書は、日本HL7協会・日本医療情報学会が公開している「診療情報提供書 HL7 FHIR 記述仕様 第1.12版（2026年2月）」と、支払基金が公開している「電子カルテ情報共有サービスの導入に関するシステムベンダ向け技術解説書 v2.0.0」です。

FHIRの基本概念について

本題に入る前に、FHIRの登場人物を3つだけ押さえておきます。

Resource（リソース）：医療情報の最小単位です。患者・医療機関・医師・病名・検査結果・処方など、一つひとつの「概念」がそれぞれResourceとして定義されています。代表的なものに Patient、Practitioner、Organization、Condition、Observation、MedicationRequest などがあります。各Resourceは、データ型・多重度・使用するコード体系（CodeSystem／ValueSet）が定義されており、システム間で共通の意味をもって情報を交換できるようになっています。

Bundle（バンドル）：複数のResourceをひとまとめにしたパッケージです。FHIRにおける情報の送受信単位であり、診療情報提供書1通も、Bundleひとつとしてやりとりされます。Bundleの type 要素を "document" にすると、文書として扱われるFHIR Documentになります。

Composition（コンポジション）：Bundleの先頭に必ず1つだけ置かれる、いわば「文書の目次」です。文書の作成日時、作成者、対象患者、タイトル、各セクションの構成（紹介目的、傷病名・主訴、現病歴、検査結果、処方内容など）を定義し、Bundle内の他のResourceを Reference（参照）で結びつけます。Compositionが存在することで、ばらばらに見えるResource群が「ひとつの文書」として意味を持つようになります。

ざっくりまとめると、Bundleという入れ物の中に、Compositionという目次があり、目次から個別のResourceに参照が張られている、という構造です。

出典：電子カルテ情報共有サービスの導入に関するシステムベンダ向け技術解説書v2.0.0　図3.FHIRデータの構造イメージ

紹介状1通をFHIRに分解してみる

それでは、紙の紹介状に書かれている項目が、FHIRでどのResourceに対応するのかを見ていきます。診療情報提供書HL7 FHIR記述仕様の表3（Bundle構成）と表5-2（Composition）を読み解くと、おおむね次のような対応関係になります。

仕様書では、診療情報提供書のBundleには Composition が必ず1つ、Patient が1つ、Practitioner（文書作成責任者・紹介先医師・紹介元医師）が1つ以上、Organization（紹介先医療機関・紹介元医療機関・文書作成機関・文書管理責任機関）が2〜4つ、と多重度（最小値・最大値）まで細かく規定されています。「最低限これは入っていなければならない」という骨組みが定義されている、と捉えるとイメージしやすいかもしれません。

Compositionが「目次」として全体をまとめる

Compositionリソースは、診療情報提供書では大きく7つのセクションを持ちます。

• 紹介先情報セクション（コード:910、必須）

• 紹介元情報セクション（コード:920、必須）

• CDA参照セクション（コード:200）／構造情報セクション（コード:300）：どちらか一方だけが必須

• 紹介目的セクション（コード:950、必須）

• 添付情報セクション（任意）

• 備考・連絡情報セクション（任意）

• PDFセクション（任意・推奨）

構造情報セクションの下には、さらに「傷病名・主訴」「現病歴」「既往歴」「アレルギー・不耐性反応」「検査結果」「投薬指示」などの子セクションが並びます。それぞれの子セクションには、対応するFHIRリソース（Condition、Observation、MedicationRequest など）が1つ以上、参照として格納される構造です。

なお、CDA参照セクションは、既に存在するCDA規約のXMLファイルをそのまま参照して再利用するためのもので、技術解説書では電子カルテ情報共有サービスでは使わないとされています。新規で記述する場合は、構造情報セクションを使うことになります。

Resourceの中身をJSONスニペットで見てみる

抽象的な話だけでは伝わりにくいので、実際のResourceがどんなJSONになるのか、具体例を2つほど見てみます。

例1：Patientリソース（患者情報）

{
  "resourceType": "Patient",
  "name": [
    {
      "use": "official",
      "text": "山田 太郎",
      "family": "山田",
      "given": ["太郎"]
    }
  ],
  "gender": "male",
  "birthDate": "1970-05-10",
  "address": [
    {
      "postalCode": "100-0001",
      "country": "JP",
      "text": "東京都千代田区千代田1-1"
    }
  ]
}

氏名が name のなかに family（姓）と given（名）として分かれて入っており、表示用のフルネームは text に格納されます。仕様書では、name.text の姓と名は半角空白1文字で連結すると規定されています。性別は gender、生年月日は birthDate、住所は address という具合に、一見「当たり前」に見える項目も、すべてが構造化されたツリーとして表現されます。

例2：Conditionリソース（傷病名）

{
  "resourceType": "Condition",
  "clinicalStatus": {
    "coding": [{
      "system": "",
      "code": "active"
    }]
  },
  "code": {
    "coding": [{
      "system": "",
      "code": "20103019",
      "display": "肺炎"
    }]
  },
  "onsetDateTime": "2026-04-10"
}

傷病名は単に「肺炎」というテキストではなく、標準病名マスタの病名管理番号（例：20103019） をコードとして付け、system で「どのコード体系のどの値か」まで明示します。これによって、医療機関Aで「肺炎」と登録された情報と、医療機関Bで「肺炎（詳細不明）」と登録された情報が、コード値を経由して同じ概念として突き合わせられるわけです。

本文ではNarrative（テキスト記述）も使えるため、機械可読なコードと、人が読むためのテキストを併用できる設計になっています。

出典：電子カルテ情報共有サービスの導入に関するシステムベンダ向け技術解説書v2.0.0　表5.Narrative と構造化データの位置づけ

JP-CLINSという「日本ルール」

ここまで紹介してきたFHIRは、HL7という国際的な標準化団体が策定した世界共通の仕様です。ただ、世界共通であるがゆえに、そのまま使うと日本の医療現場で必要な情報が「緩すぎる」状態になります。

たとえば「住所」ひとつとっても、海外の住所と日本の住所では構造が違いますし、「医療機関を一意に識別するコード」は日本では保険医療機関番号10桁が使われていますが、これは国際標準のFHIRには規定されていません。「アレルゲン」も、日本では JFAGY コードや YJ コード（個別医薬品コード）といった独自のコード体系が使われています。

そこで、FHIRに対して日本の医療現場に合わせた制約を追加した実装ガイドが用意されています。

• JP Core：日本国内でFHIR（HL7 FHIR R4）を用いて医療情報を交換するための、日本国内共通のコアプロファイル

• JP-CLINS：電子カルテ情報共有サービス向けに、JP Coreをさらに絞り込んで規定した実装ガイド（正式名称は「電子カルテ情報共有サービス FHIR 実装ガイド」）

たとえば、診療情報提供書のBundleの identifier は、JP-CLINSによって以下のような厳密なフォーマットで規定されています。

• system: http://jpfhir.jp/fhir/clins/bundle-identifier

• value: 保険医療機関番号10桁 ^ 発行年4桁 ^ 施設内で一意となる36文字以内の文字列

半角ハット記号（^）で3つの要素を連結する、というかなり具体的なルールです。同様に、傷病名コードはMEDISの標準病名マスタ、医薬品はYJコード、用法は厚生労働省電子処方箋用法コード、医療機関コードは保険医療機関番号、というように、「どこにどのコード体系を使うか」が事細かに固定されています。

令和8年3月リリース予定のFHIR記述仕様・実装ガイドでは、診療情報提供書HL7 FHIR記述仕様は Ver.1.12.0、電子カルテ情報共有サービス FHIR 実装ガイド（JP-CLINS）は Ver.1.12.0 が対象とされています。FHIRそのものの理解だけでなく、JP-CLINSのバージョンに沿った実装が求められる、というのが日本での運用上のポイントです。

Med-Wellとしての関わり

Med-Wellは、診療予約・患者コミュニケーション・地域医療連携の入り口を担うクラウドサービスです。

紹介状を電子的にやりとりする世界では、紹介予約と診療情報提供書の関係性が重要になります。たとえば、クリニックから中核病院への紹介予約をMed-Wellで受け付けたとき、そこには既に「患者情報」「紹介元医療機関」「紹介先医療機関」「受診目的」など、診療情報提供書の必須項目とかなり重なる情報が揃っていることになります。

ここから素直に発想を広げると、Med-Wellで受け付けた予約情報や問診情報を、診療情報提供書のFHIR Resourceにマッピングして「下書き」を生成する、という流れが考えられます。具体的には、Patient・Organization・Practitioner・Encounterといった「ヘッダ部」のResourceは、予約時点でかなりの精度で埋められる可能性があります。一方、傷病名・現病歴・処方・検査結果といった「ボディー部」は、電子カルテ側の情報を引き当てる必要があるため、医療機関側のシステムとの協調も視野に入れた検討が論点になります。

予約情報や問診情報を、JP-CLINSのプロファイルに沿った形でどう変換できるか、医療機関側のワークフローにどう乗せるか、を整理していくのが当面のテーマになると言えそうです。

次回（最終回）は、ここまでの仕様面の話から離れて、いよいよ「実装フェーズ」の話に移ります。ベンダー登録とは何か、接続テストはどう進むのか、といった手続き面を整理していく予定です。

結び

今回は、診療情報提供書のFHIR記述仕様を題材に、「紹介状1通の中身」がFHIRではどんな構造として記述されるのかを整理しました。

Bundle・Composition・各Resourceという3階層、そして必須セクション・任意セクションの構造、JP-CLINSによる日本独自の制約。それぞれを並べてみると、紙の紹介状という一見シンプルなドキュメントの裏側に、かなり緻密な設計が用意されていることが見えてきます。

Med-Wellは、LINEを活用した予約や呼び出し、患者コミュニケーションの仕組みを提供しています。電子カルテに依存しない形で現場の課題を解決しつつ、今後の情報連携にも対応していきます。

ご興味のある方は、お気軽にお問い合わせください。