電子カルテ情報共有サービス2文書５情報+患者サマリー　FHIR実装ガイド JP-CLINS（CLinical Information Sharing ImplementationGuide） v1.7.1
1.7.1 - release Japan

５情報送信仕様

電子カルテ情報共有サービスに医療機関から送信するデータのFHIR仕様について

本ページは、国が進めている医療DXのなかでのサービスが検討されている「電子カルテ情報共有サービス」（以下、「CLINS」という。）において扱われる、いわゆる「２文書５情報」のうち、以下の「５情報」を医療機関から送信する際のFHIR仕様に関係する部分を記述したものである。また、送信する各リソースタイプのデータをひとつのFHIR Bundleリソースに格納してまとめて送信するための仕様も記述する。

5情報、6情報のためのFHIRリソース

使用するFHIRリソースとその仕様の対応

以下の表に5情報、6情報の記述に使用するFHIRリソースとその仕様の対応を示す。

区分 情報種別 使用するFHIRリソースと仕様名 備考
5情報 薬剤アレルギー等 AllergyIntoleranceリソース
JP_AllergyIntolerance_eCS		 要素category="medication"、"biologic"(当面使用しない)とする。
その他アレルギー等 要素categoryを"food","environment"または要素なしとする。
傷病名 Conditionリソース
JP_Condition_eCS
検査 Observationリソース
JP-Observation-LabResult-eCS		 本仕様では「検査結果情報」という。
検査項目コードで検査と感染症は区別される。
感染症
処方 MedicationRequestリソース
JP-MedicationRequest-eCS		 本仕様では「処方依頼情報」という。


補足説明
  • 薬剤アレルギー等、その他アレルギー等の情報は、別に説明するように、同じプロファイルに従うAllergyIntoleranceリソースタイプで記述され、category要素に設定される値にもとづいて受信側で区別される。
  • 検査結果情報と感染症情報については、同じプロファイルに従うObservationリソースタイプで記述され、コード化された項目情報の記述にもとづいて受信側で区別される。

  • 処方依頼情報には、注射点滴手法によるものは含まれない。ただし、処方箋によって処方されるものは含まれる（自己注射剤など）。

  • 運用上の注意：処方依頼情報は、５情報のひとつとして単独で（２文書に含まれない形で）CLINSに送信されることはない。しかし、診療情報提供書、退院時サマリーの２文書に処方の内容を記述するために使用され、２文書の情報に埋め込まれてCLINSに送信されるため、その場合にはCLINSで取り出されて利用される。従って2文書に含まれる処方依頼情報は、本仕様にもとづいて記述される必要がある。

  • 上記のリソースから参照される関連情報
    　上記５情報から、その要素情報として参照されるリソースタイプを以下に示す。 ここに記載されないリソースタイプの情報も２文書ではそれぞれの仕様に従い使用可能である。

    1. 患者情報 Patientリソース
    2. 外来受診・入院歴情報 Encounterリソース
    3. 医療者情報　Practitionerリソース
    4. オーダ情報 ServiceRequestリソース JP_ServiceRequest
    5. 検査検体情報 Sepecimenリソース JP_Specimen

    上記のうち、患者情報以外のリソースは、５情報では、埋め込みリソース（containedリソース）の形で記述される。患者情報のリソースはBundleリソースのひとつのentryとして記述され、５情報からは参照の形をとる。

  • 2文書（診療情報提供書、退院時サマリー）に含まれる５情報に該当する情報の記述方法：
    　2文書の仕様書に記載されている５情報に該当する情報は、本実装ガイドに従い記述するものとする。
    CLINSでは、2文書データは文書として取り扱われるとともに、これらの文書中に記述されている５情報に該当する情報は取り出され管理される。したがって、５情報をCLINSに送信するのと同じ仕様で記述しなければならない。

  • 2文書に含まれる５情報以外の情報の記載と取り扱い
    2文書に含まれる、５情報以外の情報種別のリソースではcontainedリソースを除き、CLINSでは取り出されて単独で利用されることはない。これらのリソースを2文書内で記述する場合にはそれぞれのFHIR仕様や、JP-Core仕様に従い記述して構わない。

送信時の複数リソースデータのまとめ方

Bundleリソース（collectionタイプ）の仕様

CLINSに医療機関から送信する場合、１回に送信するリソースデータは、複数のリソースデータから構成されるのが普通である。FHIRではこのような送受信のまとめに、複数リソースデータをひとまりにしたひとつのリソースとしてBundleリソースタイプが用意されている。

Bundleリソース概要図
Bundle概要図

Bundleリソースの記述仕様の詳細については、５情報送信用Bundleリソースを参照すること。

　５情報をまとめて送信するためのBundleリソースのプロファイル

JP_Bundle_CLINS

CLINS Bundleリソース（CLINS電子カルテ情報共有サービス ５情報送信用Bundleリソース）

　５情報に該当するリソースと患者リソースのプロファイル

JP_AllergyIntolerance_eCS

AllergyIntoleranceリソース（アレルギー情報／薬剤アレルギー等）
JP_Condition_eCS

Conditionリソース（傷病名情報）
JP_MedicationRequest_eCS

診療情報・サマリー汎用 MedicationRequestリソース（処方オーダの１処方薬情報）
JP_Observation_LabResult_eCS

診療情報・サマリー汎用 Observationリソース（検体検査結果／感染症検体検査結果）
JP_Patient_eCS

Patientリソース（患者情報）


　５情報の各リソースに埋め込まれるリソースのプロファイル

  • ２文書にも含めることができる。
JP_Encounter_eCS

Encounterリソース（受診時・入院時等のEncounter情報）
JP_Practitioner_eCS

診療情報・サマリー汎用 Practitionerリソース（医療者情報）
JP_ServiceRequest

オーダー情報　JP-ServiceRequest
JP_Specimen

検査検体情報　JP-Specimen


contained リソース（埋め込みリソースの取り扱い）

FHIRでは、リソースの要素（例えば外来受診・入院歴情報を記述するencounter要素）から参照されるリソースをcontained要素に格納することで、参照される情報を包含する（埋め込む）ことができる。この方法で埋め込み記述されるリソースをcontainedリソース（正確にはContainされたリソース）と呼ぶ。containedリソースは、そのリソースタイプを通常のリソースとして記述する場合に比べて、いくつかの制限があり、例えばcontainedリソースをさらに埋め込むことはできない。 https://hl7.org/fhir/R4/references.html （2.3.0.8 Contained Resources節参照）

リソースへの参照方法

リソース要素から、他のリソースを参照する場合、その要素はReferenceデータ型となっている。
Referenceデータ型とは、次のようなFHIR仕様である。

{
  reference   0..1  string  // リテラル参照(絶対URL、相対URL、内部continedリソースID参照)
  type        0..1  uri // 参照するリソースタイプ
  identifier  0..1  Identifier // 論理参照（参照先リソースのidenfier要素のひとつを指定する）
  display     0..1  string  // テキスト代替表現
}

本仕様では、次の３通りのいずれかひとつの方法のいずれかを状況に応じて使い分ける。

（１）containedリソースをインラインリソースIDにより参照する記述方法

CLINSでは、親リソースの要素（例えば外来受診・入院歴情報を参照するencounter要素）が特定のcontainedリソースを参照する場合はこの方法を使用する。

containedリソースへの参照では、このうちreference要素とdisplay要素を使用して、そのリソースが埋め込んでいるcontainedリソースを次の方法で参照するものとする。display要素はこの参照先リソースの主要な情報を簡潔に示す文字列を仕様に従い設定する（省略可能な場合もある）。
参照先であるcontainedリソースのリソースid（id要素）に記述された値の先頭に#をつけたものを（インラインリソースIDという）、reference要素に設定する（例1）。
contained要素のリソースのidは、任意の文字列を設定できるが、contained要素を含む（親の）リソース内で一意（重複がない）となるように作成する必要がある。

例1： Reference型要素の値の例

  {
        "reference":  "#encounter203987"
        "display": "入院"
  }


例2：Observationリソースの例で、encounter要素、specimen要素がそれぞれcontainedリソースを参照しているケース （関係する要素以外については、記載を省略しているものがある）

  {
    "resourceType": "Observation",
    "contained": [
      {
        "resourceType":"Encounter",
        "id": "Encounter20240601001234101",
        "status": "finished",
        "class": {
          "system": $v3-ActCode,
          "code": "IMP",
          "display": "入院"
        }
      },
      {
        "resourceType":"ServiceRequest",
        "id": "ServiceRequest20240601001234101",
        "identifier": [
          {
            "value": "202406010239438473635623"
          }
        ],
        "status": "completed",
        "intent": "order",
        "subject": {
          "identifier": "urn:uuid:830ec2d1-67a7-427e-b6fe-ad0eb29da7fb"
        }
      }
    ],
    "status": "final",
    "subject": {
      "identifier": "urn:uuid:830ec2d1-67a7-427e-b6fe-ad0eb29da7fb"
    },
    "besedOn": {
      "reference": "#ServiceRequest20240601001234101",
      "display": "202406010239438473635623"
    },
    "encounter": {
      "reference": "#Encounter20240601001234101",
      "display": "入院"
    }
  }

［説明］Observation.besedOn要素は、reference要素にObservation.contained[1].id (ServiceRequestリソースのリソースID)の値の先頭に#をつけて記述している。同様にObservation.encounter要素にObservation.contained[0].id (EncounterリソースのリソースID)の値の先頭に#をつけて記述している。


（2）　Bundleリソースの別のentryのリソースを参照する方法（fullUrlを用いるリテラル参照） 　

CLINSでpatientリソースを参照する場合にはこの方法を使用する。

  • Bundleリソースの別のentryに参照先リソースの記述がある場合、そのfullUrl要素に設定されているUUIDを記述して参照する。


　　＜例：Reference型要素の値の例＞　（同じBundleリソース内の別のentryに記述されているfullUrlが "urn:uuid:0a48a4bf-0d87-4efb-aafd-d45e0842a4dd" であるリソースを参照する例）

  {
      "reference": "urn:uuid:0a48a4bf-0d87-4efb-aafd-d45e0842a4dd"
  }


（3）Reference.identifier要素を用いる論理参照(logical reference)

CLINSへの送信ではこの方法は用いない。

  • type要素にtype要素に参照先のリソースタイプを記述
  • identifier要素に参照先のリソースを一意に識別できる(参照先のリソースの)identifier要素のsystemとvalueを、記述


（4）display要素だけを用いてインラインで表示情報だけを記述するdisplay参照

CLINSでは、Observationリソースにおける検体情報などの記述で、この参照方式を使用している。

  • type要素にtype要素に参照先のリソースタイプを記述
  • display要素に参照先のリソースの内容を表す主要なテキスト表現をstring型で記述

　＜例：Reference型要素の値の例＞

  {
      "type": "Specimen", 
      "display": "血清"
  }

被保険者個人識別子の格納について

CLINSに医療機関から送信する場合には、個人識別子として、保険者情報と被保険者情報を、一定のルールで記述したPatientリソースを送信することが必須である。この仕様については、Patientリソースの仕様（患者情報　JP_Patient_eCS）の[セクション6][https://jpfhir.jp/fhir/clins/igv1/StructureDefinition-JP-Patient-eCS.html#%E8%A2%AB%E4%BF%9D%E9%99%BA%E8%80%85%E5%80%8B%E4%BA%BA%E8%AD%98%E5%88%A5%E5%AD%90%E3%81%AE%E6%A0%BC%E7%B4%8D]を参照すること。

長期保存の対象であることのフラグ情報の格納

CLINSに医療機関から送信する場合、送信するFHIRリソースが長期保存対象の情報である場合には、そのことを明示的に示すため、>それぞれのリソース識別子情報を設定しなければならない。
以下にその仕様を示す。

長期保存情報の仕様

リソースのデータを長期保存対象とする場合には、そのリソースのデータにおけるmeta要素のtag要素に以下の形式で記述しなければならない。
　meta.tag.system = "http://jpfhir.jp/fhir/clins/CodeSystem/JP_ehrshrs_indication"　(この固定値とする)
　meta.tag.code = "LTS"　(この固定値とする)

{
  "resourceType": "AllergyIntolerance",
  "id": "Example-allergy",
  "meta": {
    :
    <省略>
    :
    "tag": {[
      {
        "system": "http://jpfhir.jp/fhir/clins/CodeSystem/JP_ehrshrs_indication",
        "code": "LTS"
      }
    ]
    }

  },

病名情報における【未告知病名】であることのフラグ情報の格納

【未告知病名】とは、電子カルテ病名の登録済みの病名であるが、医療者がその病気の説明をまだ患者本人に対して病名やその病状を十分に説明していない段階であり、この病名情報を患者に提供する際には特別の配慮を必要とするものとして、電子カルテの病名登録画面上で、「未告知病名」として登録してある（または同様の意味あいのフラグを付与してある）病名情報のことである。 CLINSに医療機関からこの病名情報を送信する場合、送信する病名FHIRリソースにそのことを明示的に示すため、特別なリソース識別子情報を設定しなければならない。
以下にその仕様を示す。

【未告知病名】情報の仕様

病名リソース（Conditionリソース）におけるmeta要素のtag要素に以下の形式で記述しなければならない。
　meta.tag.system = "http://jpfhir.jp/fhir/clins/CodeSystem/JP_ehrshrs_indication"　(この固定値とする)
　meta.tag.code = "UNINFORMED"　(この固定値とする)

{
  "resourceType": "Condition",
  "id": "Example-condition",
  "meta": {
    :
    <省略>
    :
    "tag": {[
      {
        "system": "http://jpfhir.jp/fhir/clins/CodeSystem/JP_ehrshrs_indication",
        "code": "UNINFORMED"
      }
    ]
    }

  },
【未提供病名】情報の仕様

病名を未提供（他の医療機関にも患者さんにも提供しない病名）とする場合には、病名リソース（Conditionリソース）におけるmeta要素のtag要素に以下の形式で未提供フラグを記述しなければならない。
　meta.tag.system = "http://jpfhir.jp/fhir/clins/CodeSystem/JP_ehrshrs_indication"　(この固定値とする)
　meta.tag.code = "UNDELIVERED"　(この固定値とする)

以下の例のように他のフラグと併用できる。

{
  "resourceType": "Condition",
  "id": "Example-condition",
  "meta": {
    :
    <省略>
    :
    "tag": {[
      {
        "system": "http://jpfhir.jp/fhir/clins/CodeSystem/JP_ehrshrs_indication",
        "code": "UNINFORMED"
      },
      {
        "system": "http://jpfhir.jp/fhir/clins/CodeSystem/JP_ehrshrs_indication",
        "code": "UNDELIVERED"
      }
    ]
    }
  },