2025.1 FHIR Search ハイライト - リスト関連の検索サポート（_List、$find、機能的／「カレント」リスト

FHIR検索を、あらかじめ定義されたリソースの「リスト」ごとに制限することは、場合によってはより便利で、より効率的であり、より安全です。

バージョン2025.1より、当社のFHIRサーバーでは複数のリスト関連機能をサポートしております。

こちらでそれらを重点的にご説明し、いくつかの サンプルをご提供いたします。

一般的には、公式のFHIRドキュメントよりリストリソースの詳細について利用できます。

しかしながら、上記に基づいた簡単な 説明を以下に示します：

FHIRのリスト リストリソースは、フラット（オプションとしてオーダー付き）レコードの集合体を表し、臨床リスト（例：アレルギー、薬剤、アラート、病歴）やワークフロー管理（例：患者追跡、教育ケース）に使用されます。 リストは均質（単一のリソースタイプ）または 不均質（混合タイプ、例：状態、アレルギー・不耐性、処置にまたがる問題リスト）である場合があります。 リストは、単純なクエリでは取得できないキュレート・抽出されたデータセットが必要な場合に使用します（例：現在のアレルギーと全記録アレルギーの比較）。 リストをクエリすると、ポイント イン タイム スナップショットが得られます。 一方、リソースエンドポイントをクエリすると、通常はより広範でキュレートされていない「現時点での」データセットが返されます。

最新バージョン（2025.1以降）では、リストの操作に関する新たなサポートが追加されております：

• _list 検索パラメータ 

詳細な説明については、関連するFHIRドキュメント ご参照ください。サポート内容（特にタイプレベル検索とシステムレベル検索の差異に関する詳細）については、関連する当社ドキュメントをご参照ください。

この機能を用いることで、例えば特定のリソース（患者や遭遇記録など）のリストを定義し、それらに基づいて検索を行うことが可能となります。これにより、複数の検索パラメータとして詳細を個別に指定する必要がなくなります。

例えば、患者リストを次のように定義することができます：

PUT /List cURL snippet

curl --location --request PUT 'http://myserver/fhir/r4/List/OrgAPatients' \
--header 'Content-Type: application/fhir+json' \
--header 'Authorization: *******' \
--data '{
  "resourceType": "List",
  "id":"OrgAPatients",
  "status":"current",
  "mode":"snapshot",
  "entry": [
      {
        "item": {
           "reference": "Patient/2"
        }
      },
      {
        "item": {
           "reference": "Patient/3"
        }
      },
      {
        "item": {
           "reference": "Patient/4"
        }
      }
    ]
}'

そして、次のように検索するのです：

GET /Patient?_list cURL snippet

curl --location 'http://myserver/fhir/r4/Patient?_list=OrgAPatients' \
--header 'Content-Type: application/fhir+json' \
--header 'Authorization: *****'

そして、すべての患者様を検索パラメータで個別に指定する必要がなく、必要な患者様をキュレートされたリストとして取得できるようになります。

もちろん、他にも多くのユースケースがあります。

• 機能リスト（カスタム操作 $update-functional を含む）

特別な種類のリストとして、機能リスト（または「現在のリソース」リスト）が存在します。

詳細な説明につきましては、 関連するFHIRドキュメント をご参照ください。

ご参考までに、上記に基づいた簡単な 説明を以下に示します：

多くの臨床システムでは「現在の」患者リスト （例えば、現在の問題リストや現在の薬剤リストなど）を維持していますが、FHIRは単一のリソースインスタンスを検査するだけでは「現在性」を確実に推測することはできません。 状態 を例にとりますと、同一のリソースタイプが複数の正当な目的（キュレートされた問題リスト・エントリ、入院での苦情／診断、診断ワークフローのコンテキスト、またはインバウンド紹介データ）で投稿されますが、疾患には要素が全く存在せず 、これらの使用法を明確に区別することができません。 現在の状態と過去の状態を区別するには レトロスペクティブな変更 （完全性やデジタル署名の問題を引き起こす）が求められるため、患者様の状態 に関する通常の検索では、キュレートされた「現在の問題」だけでなく、その他の重要な状態記録も表示されます。したがって、「現在の状態のみ」に限定すると、他の重要な状態記録が隠れてしまうことになります。 したがって、ある状態（または同様のレコード）が患者の「現在のリスト」に含まれるかどうかは、 それが 適切なリストから参照されているかによって判断できます。 REST API では、これはリスト検索メカニズム  を通じて、標準的な機能リスト名を使用した _list により表現されます（例： GET [base]/AllergyIntolerance?patient=42&_list=$current-allergies)。サーバーは、独立した List インスタンスを公開することなく、これをサポートする場合があります。 いくつかの「一般的な」機能リスト名が存在します。例えば、$current-problems, $current-medications, $current-allergies, そして $current-drug-allergies （アレルギーの一種）などが挙げられます。

これらの機能リストを管理できるようにするため、$update-functional というカスタム操作を定義しました。この操作により、この種のリストの作成およびアップデートが実現できます。詳細は 当社のドキュメントをご覧ください。

現在のアレルギーのリストは、例えば以下のように定義できます：

POST /List/$update-functional?for=...&name=\$current-allergies cURL snippet

curl --location 'http://fhirserver/fhir/r4/List/$update-functional?for=34&name=%5C%24current-allergies' \
--header 'Content-Type: application/fhir+json' \
--header 'Authorization: *****' \
--data '{
  "resourceType": "List",
  "status":"current",
  "mode":"working",
  "subject":  { "reference":"Patient/34" },
  "entry": [
      {
        "item": {
           "reference": "AllergyIntolerance/159"
        }
      },
      {
        "item": {
           "reference": "AllergyIntolerance/160"
        }
      },
      {
        "item": {
           "reference": "AllergyIntolerance/161"
        }
      }
    ]
}'

これにより、特定の患者（上記の例ではID 34）に対して、$current-allergiesリストが作成または更新されます。

注： URLには患者IDを指す'for=' を含め、リスト内では患者を参照する'subject' を使用しております。

（なお、ドル記号 ($)の前にはスラッシュ(\)を付加しております。例：\$)

さて、この患者様のアレルギー・不耐性情報リソースを照会いたします。その際、全ての情報ではなく、上記のリストで定義されている「現在の」情報のみを照会することが可能です。

これは、次のように見えるでしょう：

GET /AllergyIntolerance?patient=...&_list=\$current-allergies cURL snippet

curl --location 'http://fhirserver/fhir/r4/AllergyIntolerance?patient=34&_list=%5C%24current-allergies' \
--header 'Authorization: *****'

そして、これは現在のアレルギーリストに基づき、この患者様のアレルギーのサブセットを返します。

以前ご紹介した_list検索パラメータを、今回も同様に使用しております。ただし今回は「カスタムリスト」ではなく「機能別リスト」と組み合わせております。

機能リスト名の命名については、各リストごとに制御が可能です（各リストのsubject検索パラメータはsubjectリソースタイプは; となります）。例えば上記のサンプルでは、subject 検索パラメータの patient が、subject リソースタイプのPatient)でした）、FHIRエンドポイント設定、具体的には「インタラクション戦略設定」を通じて制御可能であり、詳細は関連ドキュメントはこちらをご参照ください。これは以下のようになります：

• $find 操作

さらに、機能リストそのもの（特定のサブジェクトおよび特定のタイプのもの）を取得したい場合は、$find操作をご利用になれます。

詳細な説明については、 関連するFHIRドキュメントをご参照ください。また、 当社の関連ドキュメントも併せてご覧ください。

前の例に基づいた具体例を以下に示します：

/List/$find?patient=...&name=\$current-allergies cURL snippet

curl --location 'http://fhirserver/fhir/r4/List/$find?patient=34&name=%5C%24current-allergies' \
--header 'Authorization: *****'

これにより、上記の$update-functional関数で定義された、この患者様に関連する$current-allergiesリストが返されます。

関連する Open Exchangeアプリ which をご覧ください。こちらには上記のサンプル（さらに若干の追加内容）を含むPostmanコレクションと、@Evgeny Shvarov氏の FHIRサーバーテンプレート Dockerコンテナに対してこれを実行する方法に関する説明が含まれております（実際、上記のサンプルはこのテンプレートを基に作成されております。若干の変更を加えておりますが…詳細は アプリの使用説明書をご参照ください）。

一般的な注意点として、これらの機能はすべて、エンドポイントに対して比較的新しい、かつ現在のデフォルトであるJsonAdvSQLストレージ戦略（該当する場合は、レガシー戦略からの移行に関する詳細はこちらをご参照ください）