1.10.2 リソース間のリファレンスについて

Home ＞ Documentation ＞ Resource Definitions ＞ References [references]

There are 4 cases where elements inside a resource reference each other:

リソース内部のエレメントが相互にリファレンスする場合には次の 4 通りあります：

• Inside a CodeableConcept data type to identify the primary encoding
  • データタイプ CodeableConcept の内部で、一番元となるコードを示すリファレンス
• An <img src=""/> reference in the narrative, referring to an image found in the resource
  • ナラティブ（叙述部）の中での <img src=""/> タグからの、リソース内部に存在する画像へのリファレンス
• Between elements in the narrative and structured data elements
  • ナラティブや構造化データエレメント内での、エレメント間のリファレンス
• Between a ResourceReference and an contained resource
  • リソース ResourceReference と内包化リソースの間のリファレンス

These references are done using an id/idref based approach, where a source element indicates that it has the same content as the target element. The target element has an attribute "id" which must have a unique value within the resource with regard to any other id attributes. The "id" attribute is not in any namespace. The source element reference must refer to an attribute in the same resource (or, for a CodeableConcept, inside the same datatype).

これらのリファレンスは、id/idref を用いた手法で行われ、リファレンス元のエレメントがリファレンス先のエレメントと同じコンテンツであることを示します。リファレンス先のエレメントは、リソース内で他の "id" アトリビュートとは重複のない値である "id" アトリビュートを持ちます。この "id" アトリビュートはどのネームスペースにも属しません。リファレンス元のエレメントは、同じリソース（または、CodeableConcept の場合は同じデータタイプ）内ののアトリビュートをリファレンスしなければなりません。

In a single resource, this works like xml:id/idref, but there is an important difference: the uniqueness and resolution scope of these id references is within the resource that contains them. If multiple resources are combined into a single piece of XML, such as an atom feed, duplicate values may occur between resources. This must be managed by applications reading the resources.

ひとつのリソースの中では、これは xml:id/idref のように働きますが、次のような重要な違いがあります：リファレンスの id の重複が許されず、一致検索の対象となる範囲が、これらの id を含むリソースの中に限られるということです。ATOM フィードのように、複数のリソースがひとつの XML にまとめられた場合には、リソースの間で値の重複が起こりえます。これはリソースを読み込むアプリケーションで管理されなければなりません。

Note that all references between the xhtml elements and the data elements must be understood to establish a "derived from" relationship, where the derived content (whether text or data) refers to the source content. Note that this means some references may be forward references (references to elements defined later in the instance).

xhtml エレメントやデータエレメントの間のリファレンスはすべて、リファレンス元のコンテンツが（テキストであれデータであれ）derived 側のコンテンツとされる "derived from" の関係が成立することに注意してください。さらに、このことは、リファレンスが前方リファレンス（インスタンス上で後に定義されるエレメントへのリファレンス）のこともあることに注意してください。

The defined elements in a resource includes many references to other resources. The resources combine to build a web of information about healthcare.

リソースの定義に含まれるエレメントの中には、しばしば他のリソースへの参照が含まれます。いろいろなリソースを組み合わせて、網の目のような医療に関する情報を表現します。

References are always defined in one particular direction - from one resource (source) to another (target). The corresponding reverse relationship from the target to the source exists in a logical sense, but is not represented explicitly in the resource. Navigating these reverse relationships requires some external infrastructure to track the relationship between resources.

リファレンスは常に、リファレンス元（ソース）のリソースから、リファレンス先（ターゲット）のリソースへの一方向で定義されます。論理的には、ターゲットからソースへの逆の関係も成立しますが、それはリソースでは明示的には表現されません。このような逆の関係を辿るには、リソース間の関係をトレースするなんらかの外部のインフラストラクチャが必要です。

Because resources are processed independently, relationships are not considered to be transitive. For example, if a Condition resource references a particular Patient as its subject, and it links to a Procedure resource as its cause, there is no automatic rule or implication that the procedure has the same patient as its subject. Instead, the subject of the procedure must be established directly in the procedure itself. Another way to state this is that the context of the subject is not "inherited" and it does not "conduct" along the relationship to procedure. The only exception to this in the case of contained resources (see below). Note that in practice, the relationships do need to describe a logical and coherent record.

個々のリソースは独立に処理されるので、リソース間の関係はリソースを跨がりません。例えば、ある Condition リソースが、その記述対象として特定の Patient リソースをリファレンスするとともに、Procedure リソースにリンクして、その理由を表している時に、その Procedure リソースの記述対象として、その Patient リソースが自動的に指定されるルールはなく、その事が示唆されることもありません。その代わりに Procedure リソースの記述対象として、その Procedure リソース自体の中で、処置の記述対象としてその Patient リソースを直接リファレンスしなければなりません。言い換えると、この Condition リソースの記述対象が前述の Patient リソースであるというコンテキストはリソース間で「継承」されず、その Condition リソースからのリファレンスによって、前述の Procedure リソースまで「伝達」しないということです。このことの唯一の例外が、（後述の）内包されたリソースの場合です。実際の処理においては、リソース間の関係は論理的で首尾一貫した記録として記述しなければなりません。

In a resource, references are represented with a type, a reference, and a text description. The key property of the reference is thereference - resources are identified and addressed by their URL. The actual reference looks like this (see "XML Format" for details of the way resource contents are described):

Reference リソースは、type（リファレンス先のリソースのタイプ）、reference（リファレンス先）、display （コンテンツのテキスト表現）の 3 つのプロパティを持ちます。このうち最も重要なのは reference プロパティで、リファレンス先のリソースを、その URL で指定します。Reference プロパティの実際のフォーマットを以下に示します（リソースの XML 表記の詳細は「XML によるリソース記法」を参照ください）：

Notes: 注意：

• The type must specify the resource type, whether or not the type of the resource reference is fixed for the element in the resource definition
  • リソース定義でそのエレメントがリファレンスするリソースのタイプが固定されているかどうかに関わらず、type エレメントには、リファレンス先のリソースタイプをしていなければなりません。
• The reference element contains a url that is either an absolute URL, or a relative URL that is relative to the Service Base URL, or an internal fragment reference (see below)
  • reference エレメントには、絶対指定の URL、リソースサーバーの基底 URL を基準にした相対 URL、または（後述の）内部要素へのリファレンスのいずれかの URI が
• Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed ecosystem boundaries. (see implementation issues for further discussion)
  • 絶対指定の URL の使用は、クラウド／ウェブのコンテキストに適した安定したスケーラブルな手法となり、相対／論理リファレンスの仕様は、閉じた協業範囲での業務のやり取りに適した、柔軟な手法となります。（詳しくは実装上の問題の項を参照してください。）
• Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the tail of the url conforms to the structure "/[type]/@[id]" or "/[type]/@[id]/history/@[id]" then it should be assumed that the reference is to a FHIR RESTful server. Whether or not the reference is to a FHIR RESTful server, the reference must point to a Resource as defined by this specification
  • 絶対指定の URL は、必ずしも FHIR の RESTful サーバーを指定する必要はありませんが、それが推奨される手法です。もし URL の最後が "/[type]/@[id]" または "/[type]/@[id]/history/@[id]" の構造になっている時には、リファレンスは FHIR RESTful サーバーへ向けられたものと想定すべきです。リファレンスが FHIR RESTful サーバーに向けられたものかどうかには関係なく、リファレンスは FHIR 仕様で定義された通り、リソースの位置を示さなければなりません。
• URLs are always considered to be case-sensitive and lowercase is preferred
  • URL は常に大文字小文字の区別がされ、小文字が推奨されています
• The display is generally not the same content as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to more fully describe it
  • display エレメントは、リファレンスされたリソースの Resource.text のコンテンツとは別物になります。このエレメントの目的は、リファレンス先のリソースのコンテンツの詳細を記述することではなく、リファレンス先のリソースがどれかを特定することです。

Constraints 制約条件

• Inv-1: Must have a type if a reference is provided （reference が存在する時には type も必要） (xpath: exists(f:type) or not(exists(f:reference)))
• Inv-2: Must have a local reference if the resource is provided inline （リファレンス先が内包されたリソースの時には、reference はローカルでなければなりません） (xpath: not(starts-with(f:reference/@value, '#')) or exists(ancestor::a:content/f:*/f:contained/f:*[local-name(.)=current()/f:type/@value and @id=substring-after(current()/f:reference/@value, '#')]|/f:*/f:contained/f:*[local-name(.)=current()/f:type/@value and @id=substring-after(current()/f:reference/@value, '#')]))

「内包されたリソース」

In some circumstances, the content referred to in the resource reference does not have an independent existence apart from the resource that contains it - it cannot be identified independently, and nor can it have its own independent transaction scope. Typically, such circumstances arise where the resource is being assembled by a secondary user of the source data, such as a middleware engine. If the data available when the resource is constructed does not include record keys or absolute identification information, then a properly identified resource cannot be assembled, and even if an arbitrary identification was associated with it, the resource could never be the subject of a transaction outside the context of the resource that refers to it.

リソース中でリファレンスされているコンテンツが、リファレンス元のリソースと切りはなされたそれ自身では存在せず、独立した ID を持たず、独立した情報交換の単位とならない場合があります。よくあるのは、リソースがミドルウェア・エンジンのような、元データを二次的に利用するシステムでリソースが組み立てられる場合に、このような状況が生じます。リソースを組み立てる時に利用可能なデータにレコードの検索キーや絶対指定の ID 情報が含まれていない場合には、適切な ID を持ったリソースを組み立てることはできず、たとえ恣意的な ID を付加してリソースを生成したとしても、その生成されたリソースは、リファレンス元のリソースとは別に情報交換の対象となることはできません。

In these circumstances, the resource is placed directly in line in the reference. This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again.

このような場合、リソースはリファレンス記述に直接配置されます。この手法は、一度失われた ID を、再現することは非常に難しいので（そして、コンテンツに依存するので）コンテンツに適切な ID を付加することができる場合には決して取ってはなりません。

The type and url are always required, even though somewhat redundant in this case, to ensure that a single approach to resolving resource references can be used - simply by resolving the URL, and accessing accordingly.

この場合は、かなり冗長ですが、リソースのリファレンスを解決するのを首尾一貫した手法で行えるようにするために、type とurl エレメントは常に必要です。

Some notes about use and interpretation of contained resources:

内包されたリソースの利用と解釈を行う上でのいくつかの注意事項があります：

• Contained resources share the same internal id resolution space as the parent resource
  • 内包されたリソースは、それを収める上位リソースと同じ ID の参照範囲を持ちます
• Contained resources do not contain additional contained resources
  • 内包されたリソースは、さらに入れ子で下位の内包されたリソースを持つことはありません
• Resources that are contained inline also "inherit" context from their parent resource. For instance, if the parent resource contains a "subject", and the contained resource also has a subject element defined, but does not specify any subject, a processing application may infer that the subject is the same. Note, however, that such inferences are specific to a particular circumstance. There is no rule, for instance, that the meaning of the "subject" element is the same in both parent and contained resources
  • 内包されたリソースは、それを収める上位リソースと同じコンテキストを「継承」します。例えば、上位リソースが「記述対象」を表すリソースを別に内包している場合、その上位リソースに内装された別のリソースに、具体的な記述対象が指定されない記述対象を表すエレメントを持つ場合、その内包されたリソースを処理するアプリケーションは、上位リソースと内包されたリソースの記述対象が同一であると推定するかもしれません。しかしながら、そのような推定は、個々の状況に依ります。例えば、上位リソースと内包されたリソースの間で、「記述対象」の意味する所が同じであるというルールはありません
• Contained resources do not need to contain any narrative
  • 内包されたリソースにはナラティブ（叙述部）を含める必要はありません

Readers of the resources bundles should always look through the resources in the atom feed when a resource reference is encountered. The resource reference may have the resource type and a relative url, which is the id of the target, like this:

リソースのバンドルを読み込むアプリケーションは、リソースへのリファレンスを見つけるたびに ATOM フィードに含まれる全てのリソースを参照しなければなりません。リソースへのリファレンスは、以下のように、リソース・タイプとリファレンス先の ID である相対指定の URL を保持していることがあります：

A reader trying to find the resource this institution element identifies should always look through the entries in the atom feed prior to looking anywhere else for the institution. If the feed.id for the resource that contains the link above is http://example.org/, then the absolute URL is http://example.org/organization/@23. If that organization is in the feed, it would look like this:

この institution エレメントがリファレンスしているリソースを見つけようとする読み込み側のアプリケーションは、常に、この施設を表すリソースを他で探す前に、ATOM フィード中のエントリを探さなければなりません。もし、このリファレンスを含むリソースの feed.id が http://example.org/ であったならば、リソース先の絶対指定の URL は http://example.org/organization/@23 になります。もし、フィード中に該当する組織・施設が含まれている場合には、以下のようになります：

It would also be possible to locate the resource by an absolute url. In this case, the id element contains a direct reference to the location of the resource:

リソース先を絶対指定の URL で指定することもできます。この場合、id エレメントにはリソースの場所への直接のリファレンスが含まれます：

If there is no resource in the atom feed with an appropriate URL, then the application may try accessing the provided URL directly or use some other implementation-specific method for resolving how to find the resource.

ATOM フィードに該当する URL を持ったリソースがひとつも見つからなかった場合、アプリケーションは与えられた URL を直接アクセスするか、または実装システム特有のリソースを見つける方法でリソースへのリファレンスを解決することができます。

© 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 ドラフト仕様に基づいています。この内容に基づいてシステムを試作実装することは奨励されていますが、現在の仕様の性質上、事前の通知なしに内容の変更が行われることは、ご理解ください。