CLINS電子カルテ情報共有サービス用: 5情報　【送信用Bundleリソース】

背景および想定シナリオ

このプロファイルは、５情報を送信するためにデータをまとめる役割をするBundleリソースのプロファイルを記述するためのものである。

CLINSに医療機関から送信する場合には、ひとつのBundleリソースタイプのリソースデータを作成し、同一リソースタイプの複数のリソース・インスタンスをまとめて１回の送信で送信する。CLINSで処理対象となっていないリソースタイプのデータが含まれている場合には、受信側では処理されず破棄される（エラーとはならない）。なお、ひとつのBundleリソースタイプのファイルのサイズ上限は「電子カルテ情報共有サービスの導入に関するシステムベンダ向け技術解説書」に記述があり、上限を超えるサイズになる場合には、分割した複数のBundleリソースファイルで送信する必要があることがある。

Bundleリソースの使い方については、本ページ後段にある、

• 2.1.1 送信時の複数リソースデータのまとめ方
• 2.1.2 送信済みBundleリソース・インスタンスを指定する識別子について
• 2.1.3 Bundleリソースの送信タイミング

を参照すること。

スコープ

対象

　５情報を送信するためにデータをまとめる際に必ず使用するBundleリソースとなる。

プロファイル定義における必須要素と推奨要素

• 必須要素は、その要素が必ず１個以上出現しなければならない要素。FHIR仕様ではMust Supportフラグを設定している。
• 推奨要素は、送信側はシステムに値が存在しているなら、値を格納した要素が必ず１個以上出現しなければならず、受信側は必ずその値を格納しなければならない要素。FHIR仕様ではMust Supportフラグを設定している。

必須要素

• resourceType : リソースタイプ "Bundle"
• meta.lastUpdated : 最終更新日時
• meta.profile : 準拠プロファイル　"http://jpfhir.jp/fhir/clins/StructureDefinition/JP_Bundle_CLINS"、バージョン併記必須。
• meta.tag[n].system : このBundleが格納するリソースタイプを識別するcodeのsystem値　"http://jpfhir.jp/fhir/clins/CodeSystem/BundleResourceType_CS"
• meta.tag[n].code : このBundleが格納するリソースタイプを識別するcode
• identifier : インスタンス識別子
• type : Bundleリソースのタイプ "collection"
• timestamp : このリソースを生成した日時
• entry[0] : JP_Patient_CLINS_eCS profileに準拠したPatientリソース。
• entry[1以降] : このBundleが格納するリソース

条件により必須

• 該当なし。

推奨要素

• 該当なし。

MustSupport要素

　- 必須要素、条件により必須要素、推奨要素は、自動的にMustSupport要素である。それ以外に以下の要素がMustSupport要素である。

• 該当なし。

要素の説明とプロファイル

• 多重度欄の見方：
  • 0..1 : 最小0個、最大1個出現する。最小0個なので必須要素ではない。リスト型ではないので、要素は[　]で囲む必要はない。
  • 0..1* : 最小0個、記載されている目的をもった要素としては最大1個だけ出現する。同じ要素が別の目的で使うために複数出現することがある。（例：entry要素はPatientリソースを格納する目的では1個だけ出現するが、他のリソースを格納するためにentry要素はいくつも出現する場合など）。最小0個なので必須要素ではない。親プロファイルでは複数回数の出現が可能なリスト型であり、1個でも要素値を必ず[　]で囲む必要がある。
  • 0..* : 最小0個、最大個数制限なく出現する。最小0個なので必須要素ではない。リスト型であり、1個でも要素値を[　]で囲む必要がある。
  • 1..1 : 最小1個、最大1個出現する。最小1個なので必須要素である。リスト型ではないので、要素は[　]で囲む必要はない。
  • 1..1* : 最小1個、記載する意味での要素としては最大1個だけ出現する。同じ要素が別の目的で使うために複数出現することがある。最小1個なので必須要素である。親プロファイルでは複数回数の出現が可能なリスト型であり、1個でも要素値を必ず[　]で囲む必要がある。
  • 1..* : 最小1個、最大個数制限なく出現する。最小1個なので必須要素である。リスト型であり、1個でも要素値を必ず[　]で囲む必要がある。
• 多重度欄の背景色：
  • 濃い黄色＝「必須要素」に対応する。
  • 薄い黄色＝「条件により必須要素」に対応する。
  • 薄い緑＝「推奨要素」に対応する。
  • 無色＝本要素を記述する場合の説明を参考までに記載しているが、多重度の最小0であるため出現してもしなくてもよい。ただし、MustSupport要素の場合には、MustSupport要素としての仕様（送信側はデータを保持しているなら出力しなければならず、受信側はデータが格納されていれば受信処理をしなければならない）を満たす必要がある。MustSupport要素でなければ、データ設定と送信は任意であり、送信しても受信側では無視（破棄）されるかもしれないことに注意すること。
• この表に現れない要素であるが、JP-Coreでは出現してもよい（多重度が0..1、0..1、0..の）要素は、データ設定と送信は任意であり、送信しても受信側では無視（破棄）されるかもしれないことに注意すること。
• この表で要素名のあとに[ ]表記があるものは、値が１個であっても、JSONデータのリスト型の値で記述しなければならない。
• 要素[*] ：　この要素は繰り返し可能であり、値の記述はリストとなる。
• 要素[+] ：　（繰り返し可能な要素において）新たなひとつの要素の子要素値として記述される。
• 要素[=] ：　（繰り返し可能な要素において）すぐ上の要素と同じ要素の子要素値として記述される。

詳細説明

表 「Bundle」

表「Bundle」開く

Bundleリソースのタイプ（type要素）は"collection"を使用する。
なお、CLINSに５情報を送信する場合には、ひとつのBundlleに格納されるリソースデータ同士を相互に参照する（一方のリソースデータから同じBundle内の他のリソースを参照する）ことについては、Patientリソースだけが許容されている。 その他のリソースデータの場合には、参照元のリソース・インスタンスのcontained要素に埋め込んでインラインリソースIDにより参照する()ことが必要である。
一方、２文書を送信する場合には、文書はそれぞれひとつの”document”タイプのBundleとして作成され、ひとつのBundlleに格納されるリソースデータ同士が特に制限なく相互参照できる。
Bundleリソースのプロファイルは以下を参照すること。 CLINS電子カルテ情報共有５情報用　Bundleリソース

Bundleリソースの概要図は下図のようになる。

Bundle概要図

ひとつのBundleリソースに格納できるデータ

1回で送信するひとつのBundleリソースには、
① 「その他アレルギー等」および「薬剤アレルギー等」　AllergyIntoleranceリソース
② 傷病名情報 Conditionリソース
③ 検査結果情報および感染症情報　Observationリソース
のいずれかひとつのリソースタイプのデータと、患者を識別するためのPatientリソース1個だけを格納する。

リソースの格納順序として、患者を識別するためのPatientリソース1個をまずBundleの最初のentryに格納し、以後は上記①から③ のいずれかひとつのリソースタイプのデータを原則として１個以上格納する。

** 複数のリソースタイプのデータをひとつのBundleリソースに混在させて送信することはできない（エラーとなる）**

Bundleリソースに格納するリソース対応の指定

①から③のどのリソースタイプをBundleリソースに格納しているかの情報を明示的に設定するため、Bundleリソースの　meta.tagの次の値ペアを設定する。

• meta.tag.system : "http://jpfhir.jp/fhir/clins/CodeSystem/BundleResourceType_CS"
• meta.tag.code : ①から④に対応して、以下のいずれかの値を設定する。
  • "AllergyIntolerance"
  • "Condition"
  • "Observation"

Bundleリソースに格納するリソースのまとめ単位(1報告単位)

　1回で送信するBundleリソースには、ひとりの患者の、同時に１回で報告される一連のデータ（１報告単位のデータ）だけを、すべて漏れなく格納する。異なる報告単位のデータや、異なる患者のデータをひとつのBundleリソースに含めてはならない。
受信側（CLINS側）でデータ検証がなされる場合、１報告単位のデータはそのデータ全体がOKとなるか、全体が拒絶されるかどちらかとなる。１報告単位のデータのうち一部だけが検証にパスすることはない。
１報告単位のデータを別々のBundleリソースに分けて作成、送信したり、一部分だけ送信することはできない。もし、同じidentifier識別情報を持つBundleリソースが複数回送信された場合、最後に送信されたものだけが有効となり、それより過去に送信されたデータは削除されて上書きされるか、またはエラーとなる。
１報告単位のデータとは、情報種別により次のとおりとする。 なお、以下の説明では、終了日等とは、削除日、転帰日、完了日など、その患者に登録されていた当該情報が有効でなくなったとされた日を指す。ひとつの当該情報に終了日等が複数種類登録されている場合には、そのうち最も新しい（直近の）日付の情報とする。

①その他および「薬剤アレルギー等」（その他アレルギー等という）
１患者にその時点で登録されているか過去に登録されていたその他アレルギー等等のうち、以下のいずれかのものすべて。

• 終了日等が５年以内のもの
• 終了日等が存在しないもの なお、「その他アレルギー等」と「薬剤アレルギー等」とは区別しない。

②傷病名情報
１患者にその時点で登録されているか過去に登録されていた傷病名情報のうち、以下のいずれかのものすべて。

• 終了日等が５年以内のもの
• 終了日等が存在しないもの

③ 検査結果情報および感染症情報
１患者の１回の検査結果報告で報告された一連の検査の結果が1報告単位となる。１回の検査結果報告で感染症情報とそれ以外の検査結果情報とが混在している場合にも、それらを区別せずに１報告単位のデータとみなしてよいが、別々の検査結果報告として異なる報告単位のデータとしてもよい。ただし、異なる報告単位のデータとするときは、異なるBundle.identifier識別情報とする必要がある。

Bundleリソースを識別するIdentifier要素

Bundleリソースのidentifier要素は、CLINS側で保存される。送信側は、後続の送信において同じidentifierを使用することで、過去に送信したBundleリソース・インスタンスを削除、更新などの処理対象を指定できる。
Bundleリソースのidentifier要素は以下の通りとする。
この仕様を満たすidentifierに加えて、これとは異なるsystem値をもつidentifierは複数存在しても構わない。

Bundle.identifier.system : "http://jpfhir.jp/fhir/clins/bundle-identifier" を設定する。
Bundle.identifier.value : 以下に記載する[Bundle-ID]　(旧報告単位ID)を設定する。

[Bundle-ID]： 次の３つの文字列を半角ハット記号（^）で連結した文字列。

• 保険医療機関番号10桁：
  　（内訳：都道府県番号２桁、点数表コード（医療機関区分）１桁、医療機関番号７桁）
• 発行年：
  　　Bundleリソースを作成した発行年（西暦）4桁
• 施設内ID：
  　　施設内において発行年内にCLINSに新規に送信したBundleリソースを通して一意となる（重複がない）番号
  　半角英数字および半角ハイフン（U+002D）だけからなる36文字以内の可変長文字列。

Bundleリソース・インスタンスの例（JSON形式）：

{
    "resourceType": "Bundle",
    "id": "Bundle-for-Example01",
    "meta": 
      {
        :
        <省略>
        :
      },
    "identifier": [
      {
        "system": "http://jpfhir.jp/fhir/clins/bundle-identifier"
        "value": "1311234567^2024^ORDLAB-20230301O102930492039"
      },
        :
        <省略>
        :
    ],
    "type": "collection",
    "timestamp": "2020-08-21T12:12:21+09:00",
    "entry": [
        {
            "fullUrl": "f5f8bd72-4759-4fee-9cfe-4daf587abe68",
            "resource": {
                "resourceType": "Patient",
                "id": "JP-Patient-10293894",
                :
                <患者基本情報を格納するPatientリソース内容>
                :
            }
        },
        {
            "fullUrl": "f01d4ed2-a79f-bf5e-0232-5ae62dd34d63",
            "resource": {
                "resourceType": "Observation",
                "id": "JP-Observation-Example001",
                :
                "subject": {
                  "reference": "f5f8bd72-4759-4fee-9cfe-4daf587abe68"
                  <上のUUIDは、上記PatientリソースのfullUrlの値を設定することで上記患者リソースを参照している。>
                }
                :
                <１個目の検査結果><省略>
                :
            }
        },
　　　　　＜2個目、3個目、...の検査結果Observationリソース＞
    ]
}

Bundle内のentryの識別子（fullUrl）

Bundle.entry[] に繰り返しで格納される個々のリソース・インスタンスは、必ずBundle.entry[].fullUrl要素に、uuidをその都度毎回生成して異なる値を設定しなければならない。
1回で送信するひとつのBundleインスタンスの中に同一のuuidが存在してはならない（エラーとなる）。
同じリソースインスタンスを別のBundleリソースにより再送する場合は、前回送信時に使用したuuidをしてもよいが、新たに生成してもよい。

このuuidによるBundle内のentryの識別子(fullUrl)を、前回送信時の特定のentryの内容を受信側に指し示すための識別子として利用することはできない（受信側で保存していない）。

送信済みBundleリソース・インスタンスを指定する識別子について

対象となるBundleリソース・インスタンスの指定

CLINSに送信した１報告単位のデータ(ひとつのBundleリソースにまとめて送信したデータ)は、この単位で全体を削除するか、更新（削除＋新規登録）するかいずれかのみ行うことができる。１報告単位のデータのなかの特定のリソースだけを指定した削除や更新はできない。 対象となる送信済みのBundleリソース・インスタンスの指定は、前述した [Bundle-ID] により行う。

電子カルテ情報共有サービスでの削除と更新処理

• 削除処理、更新処理： 削除要求コマンドまたは更新処理要求コマンドが、①被保険者個人識別子、②Bundle.identifier.system値、③Bundle.identifier.value値、の3つのパラメータとともに送信される。

  • 削除要求の場合: 対象となるBundleリソースそのものは送信しない。共有サービスでは、①②③がすべて一致するBundleリソース・インスタンスのデータを削除する。

  • 更新処理： 共有サービスでは、①②③がすべて一致するBundleリソース・インスタンスのデータを削除する。次に、送信されたBundleリソース・インスタンスのデータを登録する。

なお、CLINSでは、削除処理、更新処理のどの過程でも途中で失敗、エラーとなった場合には、全ての処理をロールバックし、処理前の状態に戻す。

以上のCLINSの処理要件を満たせるよう、Bundleリソースインスタンス、Patientリソースインスタンスには、本仕様に従って①②③を設定しなければならない。

Bundleリソースの送信タイミング

Bundleリソースの電子カルテ情報サービスへの送信タイミングについては、CLINSの運用ルールに従うため、本IGの範囲外であるが、以下の方針を前提として本IGは作成されている。

① 「薬剤アレルギー等」「その他アレルギー等」の情報　AllergyIntoleranceリソース、および　② 傷病名情報 Conditionリソース

　　送信タイミングは、外来受診（複数診療科同日受診は１回とみなす）、入院、退院のイベントのあった日、およびこれらの情報が「新規登録または一部が更新、削除」（以下、「更新等」という）された時点ごととする。原則として、当該イベントや時点の当日中（翌朝までの夜間を含む）とする。

③ 検査結果情報および感染症情報　Observationリソース

　　送信タイミングは、これらの情報が更新等された時点ごととする。原則として、当該時点の当日中（翌朝までの夜間を含む）のなるべく早い時点が望ましいが、遅くとも次回診療日中（翌朝までの夜間を含む）とする。

詳細は、厚生労働省のホーページ「電子カルテ情報共有サービス」サイトの「電子カルテ情報共有サービスの導入に関するシステムベンダ向け技術解説書」の「原則->速やかな登録・取得」を参照。

その他、参考文献・リンク等

特記事項なし