1.10.1 タグ、バンドル、コンパートメント

Home ＞ Documentation ＞ Resource Definitions ＞ Tags, Bundles, Compartments [extras]

In addition to the basic contents of Resources, and their metadata, each resource can be labelled with one or more "Tags". These tags can be used to associate additional operational information with the Resources, including defining security labels used in access control policies, workflow management, and other uses. Tags are attached to resources, and exchanged with their resource. Tags are never used to keep information that needs to be understood when interpreting the content of a resource; their function is limited to finding and controlling access to the resource.

リソースの基本要素であるコンテンツとメタデータに加えて、リソースには「タグ」と呼ばれるラベルを複数個つけることができます。このタグを使うことで、アクセスポリシーの制御に使うセキュリティラベルの定義や、ワークフロー管理といった、リソースの運用に関する追加の情報を付加することができます。タグには、リソースのコンテンツの解釈時に考慮すべき情報の保持に使われることは決してありません。タグの機能はリソースの特定やアクセス制御に限定されます。

Each tag has two properties:

タグは以下のふたつのプロパティを持ちます：

The URI may be a reference to a healthcare vocabulary, including ones defined in this specification, such as the basic security label set, or vocabularies such as those defined by HL7 (v2 and v3/CDA), LOINC, or SNOMED-CT. Alternatively, the URI may be one defined by the implementation in the local context. Literal references that refer directly to a description of the tag (typically just an HTML page) are preferred over symbolic references but this is not required.

URI に指定できるのは、ひとつには医療保健情報交換のボキャブラリで、セキュリティラベルの基本集合などFHIR 仕様で定義されるものや、HL7（v2 または v3/CDA）や、LOINC や、SNOMED-CT 等のボキャブラリが含まれます。それ以外には、URI にローカルのコンテキストにおける実装システムで定義されたものを指定できます。URI は、必ずしもそうである必要はありませんが、タグを説明した記述（普通は単純な HTML のページ）へ直接アクセスできるリファレンスのほうが、判別用のシンボルとしてのリファレンスよりも望まれます。

If the end user application provides functionality to the user that allows the user to affix arbitrary text tags to the resource for their own purpose, the application can automatically construct a URI by appending the mime encoding of the Label to the base URL "http://hl7.org/fhir/tags/text/". When applications processing resources see this base URL, they can automatically know that this is a pure text label with no formal meaning.

エンドユーザーのアプリケーションが、ユーザー自身の用途にリソースに任意のテキストのタグを付加できる機能を提供している場合には、アプリケーションは、そのラベルを MIME エンコーディングしたものを、URI の基本部分 "http://hl7.org/fhir/tags/text/" につなげることで、自動的に URI を生成できます。そのリソースを処理するアプリケーションが、この URI の基本部分を見た時には、自動的に公式な意味が付加されていない単なるテキストのラベルとして認識されます。

Each resource may belong to one or more logical compartments. A compartment is a logical grouping of resources which share a common property. Compartments have two principal roles:

それぞれのリソースはいくつかの論理的コンパートメントに属することができます。コンパートメントは共通のプロパティを共有するリソースの論理的なグループです。コンパートメントには以下のふたつの主要な役割があります：

• Function as an access mechanism for finding a set of related resources quickly
  • 関連する複数のリソースの集合を素早く見つけるためのアクセス手段としての機能
• Provide a definitional basis for applying access control to resources quickly
  • リソースに素早くアクセス制御を適応するための対象グループを設定する

Compartments define how particular instances of the compartment are defined and identified, and how systems know whether resources are in the compartment or not. Here is a list of the compartments defined by this specification:

コンパートメントが定義するのは、コンパートメントの特定のインスタンスがどのように定義され識別されるか、システムがどのようにあるリソースがコンパートメントに属するかを知るかということです。以下は FHIR 仕様で定義されているコンポーネントの一覧です：

As an example of compartment usage, to retrieve a list of a patient's conditions, use the URL:

コンパートメントの使用例として、ある患者の状態のリストを取得するには URL を利用して：

GET [baseurl]/patient/@[id]/condition

The details of this usage are described under the search operation.

この使い方の詳細については検索操作について項目の中で記述されています。

Compartments may be used explicitly, like this, but can also be used implicitly. For instance, if a FHIR server is providing a patient view of a record, the authorised user associated with use of the FHIR RESTful api may be limited to accessing records from the compartment instance(s) logically associated with their identity.

コンパートメントは上記の例のように明示的に使用されるほかに、暗黙的にも使われます。たとえば、FHIR サーバーがデータレコードの患者単位の表示を提供している場合に、FHIR RESTful API を使用する権限を持ったユーザーは、アクセスが許可された ID に論理的に関連づけられたコンパートメントのインスタンスに含まれるデータレコードだけに、アクセスが制限されるといったことがありえます。

Note that resources may cross between compartments, or interlink them. Examples of this would be where a Diagnostic Report identifies a subject, but an Observation it references identifies a different subject, or where a List resource references items that identify different subjects. Such cross-linking may arise for many valid reasons, including:

リソースはコンパートメントを跨いだり、リンクが交差することがあることに注意してください。このような状況の例としては、Diagnostic Report リソースがある記録対象の ID を持っている時に、そのDiagnostic Report リソースのリファレンスしている Observation リソースが別の記録対象の ID を持っている場合や List リソースがリファレンスしている項目が別々の記録対象の ID を持っているような場合があります。このような交差リンクが起こる正当な理由には、以下のような例が含まれます：

• Cases where subject records are inter-linked - Transplants, Perinatal care, family therapy etc.
  • 記録対象のデータレコードが相互リンクされている場合 ー 移植、周産期医療、家族療法など
• Workflow management where action lists link multiple patients and/or practitioners
  • アクションリストが複数の患者や医療従事者とリンクされるワークフロー管理

Given the wide variety of use cases and contexts in which FHIR is used, compartments do not define how cross-linking is handled. Systems may reject resources, remove them from both compartments, or place them in both, or act in some other fashion.

FHIR が使用されるユースケースやコンテキストの多様さを考慮して、コンパートメントがどのように交差リンクを取り扱うかは定義されていません。システムがリソースを拒否する場合や、両方のコンパートメントから取り除く場合や、あるいは両方のコンパートメントに所属させる場合や何らかの別の処理を行う場合が考えられます。

One common operation performed with resources is to gather a collection of resources into a single instance. In FHIR this is referred to as "bundling" the resources together. The resource bundle is not just a list of references to resources, but includes their whole content. These resource bundles are useful for a variety of different reasons, including:

リソースに対して行われる共通の操作のひとつに、リソースの集まりをひとつのインスタンスにまとめることがあります。FHIR ではこの操作をリソースを「バンドルする」と呼びます。リソースのバンドルは単なる複数のリソースへのリファレンスのリストではなく、関連するすべてリソースのコンテンツを含みます。このようなリソースのバンドルは、以下のような様々な理由から有用です：

• Returning a set of resources that meet some criteria as part of a server operation
  • サーバーの操作の一部として、ある条件に合致するリソースの集合を返すとき
• Returning a set of versions of resources as part of the history operation on a server
  • サーバーの履歴確認操作の一部として、リソースの今までの一連のバージョンを返すとき
• Storing a collection of resources
  • ひとまとまりのリソースを格納するとき
• Exchanging a set of resources as part of a message transaction
  • メッセージ交換の一部として、リソースの集合を渡すとき
• Grouping a self-contained set of resources to act as an exchangeable and persistable group with clinical integrity (i.e. a clinical document)
  • あるリソースに内包された一群のリソースを、医療上意味のある塊（例：診療文書）として独立で交換あるいは永続的に保存可能にするとき

Conceptually, a bundle has an identifier (url) and a date updated, and a list of resources. For each resource in the list, the bundle has the resource and also its metadata as listed above. Each entry in the bundle retains its original identifier. This means that applications reading the bundle should always look for a resource by its identity (after converting relative URLs absolute URL) in the bundle first before trying to access it by its URL.

概念的には、バンドルは、ID（URL）と更新日時とリソースのリストからなります。リストに含まれる個々のリソースについて、バンドルはそのリソース本体に加えて上述のメタデータも保持します。バンドルに含まれるリソースは、元々のIDをそのまま維持しています。したがって、バンドルを処理するアプリケーションは、常にまずバンドル中のリソースを特定するのに、バンドルのURLではなく、最初は（相対 URL を絶対 URL に変換した後で）バンドル中のリソース自身の ID を使って探さなければなりません。

© HL7.org 2011 - 2013. FHIR v0.11-1712 generated on Fri, Sep 6, 2013 23:04+1000.

Warning: This version of FHIR is the DSTU ballot, and the stable version for the September/October connectathons. Implementers are welcome to experiment with the content defined here, but should note that the contents are subject to change without prior notice.

この日本語訳は、上記のバージョンの FHIR ドラフト仕様に基づいています。この内容に基づいてシステムを試作実装することは奨励されていますが、現在の仕様の性質上、事前の通知なしに内容の変更が行われることは、ご理解ください。