1.10 リソースに関する諸定義

Home ＞ Documentation ＞ Resource Definitions [resources]

Resource Definitions 「リソースの定義」 1.10.0

A resource is an entity that:

リソースは以下を満たすエンティティです：

has a known identity by which it can be addressed
- 何らかの既知の識別情報で特定する事ができる
identifies itself as one of the resource types defined in this specification
- この仕様で定義されているリソース・タイプのいずれかに属している
contains a set of structured data items as described by the resource definition
- リソース定義に記述されている一連の構造化されたデータ要素を含んでいる
contains a human readable XHTML representation of the content of the resource
- リソースのコンテンツについての人間が読むことのできる XHTML 表現を含んでいる
may change over time
- 時間の経過とともに変化しうる

Resources have multiple representations. A resource is valid if it meets the above rules, and is represented in either XML or JSON according to the rules defined in this specification. Other representations are allowed, but are not described by this specification.

リソースには複数の表現形式があります。リソースは、上記のルールを満たし、この仕様で定義されたルールに従って XML または JSON 形式で表現された場合に、標準に準拠していると見なされます。他の表現形式を使うことも許されていますが、それらの表現形式はこの仕様書には記述されません。

This specification defines a series of different resource types that can be used to exchange and/or store data in order to solve a wide range of healthcare related problems, both clinical and administrative. In addition, this specification defines several different ways of exchanging the resources.

この仕様書で定義されるさまざまなタイプのリソースは、診療部門・事務部門を問わず医療に関連した幅広い領域の課題解決のための情報交換や情報集積に用いることができます。それに加えて、この仕様書では、リソースの交換手段としていくつかの異なる方法を定義しています。

Contents of a Resource 「リソースのコンテンツ」 1.10.0.1

All resources have the following aspects:

全てのリソースは以下の様相を持ちます：

A base set of defined data elements
- 規定の基本データエレメント
Extensions (optional) - additional data elements added by implementations (see "Extensibility")
- 拡張部分（オプション）− 実装毎に追加される追加データエレメント（"Extensibility"を参照）
A human readable narrative description of the contents of the resource (see "Narrative")
- 人間が読むことを意図したリソースの叙述的記載（"Narrative"を参照）
Contained resources - additional resources that are part of the identification and transaction space of this resource
- 内包リソース − 独立した個別のＩＤを持たないため、情報交換の都合上、リソースに内包されたリソース（後述）
Metadata - important information about the resource that is not part of the content model of the resource
- メタデータ − リソースのコンテンツ・モデルに含まれない、リソースに関する重要な情報
Tags - labels affixed to the resources that may be used to define additional operational behaviour such as security, workflow, etc.
- タグ − セキュリティやワークフローといった、FHIR 標準の範囲外の運用上の振る舞いを定義するのに用いるリソースに貼付されたラベル

The contents of the base resource from which all other resources derive are:

全てのリソースの基本モデルとなる基底リソースのコンテンツは以下の通り：

<[Name] xmlns="http://hl7.org/fhir"> <extension></extension> <language value="[code]"/> <text></text> <contained></contained>  </[Name]>

These elements must always appear in this order. These basic elements shared by all resources come first in order to support consistent definitions for schema and UML derived code.

ここに示されたエレメントは、常にこの順番で出てこなければなりません。全てのリソースに共通するここで上げた基本エレメントは、スキーマや UML から生成されたコードが首尾一貫して動作するよう、最初に出てくるようになっています。

The optional language element specifies the base language of the resource using the codes defined in BCP 47. Note that not all the content of the resource has to be in the language. If a language is specified, it should also be specified on the Narrative Text.

省略可のエレメント language は、 BCP 47 で定義されたコードを使って、リソースのベースの言語を指定します。リソースの全てのコンテンツがここで指定された言語でなくてもよいことに注意してください。要素 language を指定した時には、Narrative でも同様に指定してください。

The language element is provided to support indexing and accessibility (e.g. text-to-speech use the language tag). The html language tag in the narrative is used when processing the narrative. The language tag on the resource is provided for use to specify the language of alternate presentations generated from the data in the resource

エレメント language は、索引作成やユニバーサル・アクセス（読み上げシステムによる言語タグの仕様）のために用意されています。 narrative における HTML の language タグは、narrative を処理する時に使用されます。リソースの language タグは、リソースのデータから生成される代替表示の言語を決定するのに使用されます。

Resource Metadata 「リソースのメタデータ」 1.10.0.2

The metadata properties are key aspects of the resource and how it behaves. For implementation reasons, these are represented outside the resource:

メタデータ属性は、リソースの識別 ID とリソースの振る舞いを表します。これらは実装上の理由から、リソース本体の外部に置かれます：

Note that the version id changes any time the resource changes, and so does the last modified date. The Version Id is more useful for managing concurrency issues and version specific references because of the inherent uncertainties and precision limits associated with date times. The Last Modified Date is useful for a human to ascertain the logical currency of the information in the resource.

Version Id と Last Modified Date は、リソースに変更がある度に変更されることに注意してください。Version Id は同時更新や、特定バージョンへのリファレンスを管理するのに、日時にかかわる固有の不確定性や精度の限界から Last Modified Date よりも有用です。Last Modified Date は、リソースの情報の論理的妥当性について、人間が確かめるのに有用です。

In any environment where the resources are used, the technical details of how these metadata elements are represented will need to be resolved. For further details, see Implementation Details, which also contains a discussion of how resource identity is maintained.

リソースが使用されるどのような環境においても、これらのメタデータがどのように表現されるかの技術的詳細が合意される必要があります。詳細については（実装の詳細）の項を参照してください。そこではリソースの識別情報の維持管理についても議論されます。

Resource ids are case sensitive. Ids are always opaque, and systems need not and should not attempt to determine their internal structure. However the id is represented, it must always be represented in the same way in resource references and URLs. Ids can be up to 36 characters long, and contain any combination of ASCII letters, numerals, "-" and ".".

リソースの id は大文字小文字を区別します。id の値が意味を持つことはなく、その内部構造をシステムが解析する必要はなく、また解析しようとすべきではありません。id がどのように表現されるかに関わらず、リソース参照や URL に全く同じ表現を常に使わなければなりません。いずれの id も最大 36 文字で、ASCII 文字、数字、"-" と "." の任意の組み合わせです。

Conformance 「コンフォーマンス」 1.10.0.3

The contents of the resource and the formats used to represent it must conform to the rules described in this specification. Because of its general nature and wide applicability, the rules made in this specification are generally loose compared to the rules suitable for particular use cases. This specification provides a conformance layer that implementers and national/regional programs can use to provide a computable statement about how the resources and their exchange paradigms are used to solve particular use cases. This conformance layer is delivered through use of the Conformance and Profile resources.

リソースのコンテンツとそれを表現するためのフォーマットは、この仕様に規定されたルールに従わなければなりません。その一般的性格と適応範囲の広さから、この仕様で決められたルールは特定のユースケースに適用されるようなルールと比べれば全般的に緩やかなものとなっています。この仕様ではコンフォーマンス・レイヤーが提供されていて、実装者と国あるいは地域の医療情報交換事業との間で、特定のユースケースのの実現に用いるリソースや情報交換手法の利用方法について、コンピューターで検証可能な記述を用意するのに用いることができます。コンフォーマンス・レイヤーは、 Conformance および Profile リソースを用いて実現されます。

The specification also provides a number of technical resources that can assist with enforcing conformance to this base specification:

この仕様では、他にも、ベースとなる仕様へのコンフォーマンスを義務づける助けとなるいくつもの技術的リソースが提供されています：

Schema & Schematron
- スキーマ＆スキーマトロン
Validator Package
- 検証用パッケージ
Reference Platforms
- 参照プラットフォーム

Note that none of these are able to check complete conformance to this specification.

上記のいずれも、本仕様への完全なコンフォーマンスを検証することはできないことに注意してください。

The data elements defined resources and data types have 4 properties that are directly related to conformance: Cardinality, Is-Modifier, Must-Support, and Cardinality. These interact to place conformance requirements on implementations.

リソースやデータタイプを定義するデータ要素は、コンフォーマンスに直接関係する 4 つのプロパティを持っています：Cardinality、Is-Modifier、Must-Understand、Must-Support および Cardinality です。これらは連携して働いて、実装におけるコンフォーマンス要件を定めます。

Cardinality 「カーディナリティ・プロパティ」 1.10.0.3.1

All elements defined in FHIR have a cardinality as part of their definition - a minimum number of required appearances, and a maximum number. This number specifies the number of times the element may appear in any instance of the resource type. This specification only defines the following cardinalities: 0..1, 0..*, 1..1, and 1..*. Profiles that describe specific use cases may use other values for cardinality within the limits of the cardinality defined by the resource.

FHIR で定義される全てのエレメントの定義にはカーディナリティ（cardinality）というプロパティが含まれ、インスタンスに出現する最小限と最大限の数が指定されています。そこで指定された数は、該当するリソースタイプにおけるエレメントの出現数について、すべてのインスタンス適用されます。この仕様で指定されるカーディナリティは次のパターンに限られます： 0..1、０..*、1..1、および 1..* です。特定のユースケースを記述するプロファイルでは、リソース定義で指定されたカーディナリティの範囲内で、それ以外の値を指定することができます。

Note that when present, elements cannot be empty - they must have either a value attribute, child elements, or extensions.

出現した場合には、エレメントは空にはできないことに注意してください。エレメントは、値を持つアトリビュートか、下位エレメントかエクテンションを持つ必要があります。

In this specification, very few elements have a minimum cardinality of 1. Resources are used in many contexts, often quite removed from their primary use case, and sometimes even basic information is sometimes very incomplete. For this reason, the only elements that have a minimum cardinality of 1 are those where they are necessary to any understanding of the element that contains them. The minimum cardinalities should not be taken as a guide to which elements are expected to be present in any particular use of the resource.

この仕様では、最小のカーディナリティとして 1 を持つエレメントはごく限られています。リソースは、様々なコンテキストで、しばしば元々のユースケースとは切り離されて使用されるので、時には基本的な情報すら完全には埋められていないことがありえます。この理由から、最小のカーディナリティとして 1 を持つエレメントは、そのエレメントを含む要素のどんな解釈にもそのエレメントの出現が必要な場合に限られます。リソースの特定の使用方法において、最小のカーディナリティを、どのエレメントが出現することが見込まれるかの参考には用いるべきではありません。

For elements that have cardinality > 1, the order in which they appear may have meaning. Unless the element definition (either in this specification or the extension) defines a meaning to the order explicitly, the meaning of the order is not defined, and implementations are allowed to reorder the elements. Note that you cannot define a meaning for the order of the elements in a profile. When there is no definition of the meaning of the order, implementations that need to choose a single element from a list of elements for some use must do so based on the semantics of the content of the elements that repeats. Profiles and Implementation guides may often make rules about this selection process.

カーディナリティが 1 を越えるエレメントについては、エレメントの出てくる順番が意味を持つことがあります。（この仕様か、あるいはエクステンション仕様のいずれかで）エレメントの定義として明示的に順序の意味が定義されない限り、順序の意味は未定義となり、実装システムはエレメントの順番を変えることが許されます。プロファイルではエレメントの順番の意味を定義できないことに注意してください。順番の定義の意味がない時には、何らかの目的で要素のリストから単一の要素を選択する実装システムでは、繰り返しの要素のコンテンツのセマンティックスに基づいて選択しなければなりません。プロファイルや実装ガイドでは、しばしばこのような選択プロセスについてのルールを定めていることがあります。

Is-modifier 「イズ・モディファイア・プロパティ」1.10.0.3.2

Is-Modifier is a boolean property that is assigned when an element is defined, either as part of the base resource contents in this specification, or when profiles declare extensions. An element is labelled "Is-Modifier = true" if the value it contains may change the interpretation of other elements or the resource as a whole. Typical examples of elements that are labelled "Is-Modifier" are elements such as "status", "active", or "certainty". The value of Is-Modifier cannot be changed when element usage is described in a Resource Profile. When an element is labelled as Is-Modifier, the documentation must be clear about why it is a modifier, and/or which elements the element may modify.

モディファイア・フラグ（Is-Modifier）は真偽値のプロパティで、エレメントが定義される時に、FHIR 仕様のリソースの基本コンテンツの中か、プロファイルでのエクステンション宣言の中で与えられます。エレメントの格納する値が、他のエレメントやリソース全体の解釈を変化させる場合に、"Is-Modifier = true" と設定されます。"Is-Modifier = true" と設定されるエレメントの典型的な例としては、"status"、"active" あるいは "certainty" といったエレメントです。リソース・プロファイルにエレメントの使用方法を記述する際に、モディファイア・フラグの値を変更することは出来ません。エレメントのモディファイア・フラグが真に設定された時には、エレメントの記述で、なぜモディファイア・フラグが真なのか、どのエレメントに影響を与えるのかについて記述しなければなりません。

Generally, elements labelled "Is-Modifier = true" also have a minimum cardinality of 1, to introduce certainty in their handling. If the value of such an element is not explicit in the instance, or known by the context, the resource cannot be safely understood. Irrespective of the minimum cardinality, implementations producing resources SHALL ensure that appropriate values for isModifier elements are provided. Is-Modifier elements SHALL be represented in the narrative summary of the resource.

一般的に、モディファイア・フラグが真のエレメントは、その処理を確実にするために、最小のカーディナリティも 1 となります。もし、そのようなエレメントがインスタンスに明示的に存在せず、またコンテキストからも判別できない場合には、リソースを安全に解釈できないからです。最小のカーディナリティの設定に関わらず、リソースを生成する実装システムは、モディファイア・フラグが真のエレメントに確実に適切な値が与えられるようにしなければなりません。モディファイア・フラグが真のエレメントはリソースのナラティブによるサマリに表現されるようにしなければなりません。

Implementations processing resources SHALL understand the impact of the element when they process the resource. Implementations are not required to "support" the element in any meaningful way - they may achieve this by rejecting instances that contain values outside those they support (for instance, an application may refuse to accept observations with a reliability != "ok"). Alternatively, implementations may be able to be sure, due to their implementation environment, that such values will never occur. However applications SHOULD always check the value irrespective of this.

リソースを処理する実装システムは、リソースの処理の際に、モディファイア・フラグが真のエレメントの影響を理解しなければなりません。実装システムはそのようなエレメントを「サポート」する必要はありませんが、何らかの合理的なやり方で処理します。（訳注：ここは記述が抜けているように思われるので意味を補いました。）これは、サポート外の値を持ったインスタンスを拒否する（例えば、アプリケーションは、realiablility != "ok" の場合、検査結果を受け取るのを拒否することができます）ことで達成することもできます。そのかわりに、実装システムは、実装環境によって、そのような値が決して起こらないようにすることを選ぶこともできます。しかしながら、そのような仕組みの有無にかかわらず、アプリケーションは常に値を検証しなければなりません。

Servers and background processes that move resources around are not "processing the data of the resource", and these applications are not required to check for unknown extensions. Any process that copies data out of a resource for use in another context (display to a human, decision support, exchange in another format that doesn't support extensions) is processing the data.

サーバやバックグランド処理のような「リソースのデータの処理を行わない」リソースを移動させるだけのアプリケーションは想定外のエクステンションを検証する必要はありません。しかし、別のコンテキストで使うためにリソースからデータを取り出してコピーする処理（人間に対する表示、意思決定支援、エクステンションをサポートしない別のフォーマットでの情報交換）は、データを処理していることになります。

Must-Support 「マスト・サポート・プロパティ」 1.10.0.3.3

Labelling an element Must-Support means that implementations that produce or consume resources must provide "support" for the element in some meaningful way. Exactly what this means is impossible to describe or clarify as part of the FHIR specification.

あるエレメントに Must-Support が指定されているときには、そのリソースを生成または処理する実装システムは、そのエレメントはなんらかの意味のある形で「サポート」しなければなりません。この記述が正確にどのような意味を持つかは、FHIR 仕様の中では、記述することや明確にすることはできません。

For this reason, the specification itself never labels any elements as must-support. This is done in Resource Profiles, where the profile labels an element as mustSupport=true. When a profile does this, it must also make clear exactly what kind of "support" is required, as this can mean many things.

そのため、この仕様自体では、エレメントに Must-Support を指定することはありません。この指定は、リソース・プロファイルで mustSupport=true を設定することで行われます。プロファイルでこの指定が行われる時には、それだけでは色々な解釈ができるので、正確にどのような「サポート」が必要とされるかを、明確にしなければいけません。

Note that an element that has the property IsModifier is not necessarily a "key" element (e.g. one of the important elements to make use of the resource), nor is it automatically mustSupport - however both of these things are more likely to be true for IsModifier elements than for other elements.

IsModifier プロパティを持つエレメントが必ずしも「キー」・エレメント（つまり、リソースを使用するにあたって重要な役割を持つエレメント）ではなく、mustSupport が指定されているとは限らないことに注意してください。しかしながら、IsModifier の指定されたエレメントについては、そうでないエレメントに比べて、上記ふたつの条件が成立する場合が多くなります。

Inter-version Compatibility 「バージョン間の互換性」 1.10.0.4

The following rules will apply once the specification becomes a full normative specification. These rules ensure that implementations may process the content of the resources safely while exchanging data between applications using different versions of FHIR. However during the period of trial use of the specification, HL7 may make changes outside the limitations described here in response to discovered issues in the specification. Applications may wish to use resource tags to help manage this during the period of trial use.

以下の規則は、FHIR 仕様が、完全な正式仕様になった後で適応されます。これらの規則は、異なるバージョンの FHIR を使用するアプリケーション間でデータ交換を行う時に、実装システムがリソースのコンテンツを問題なく処理できることを保証します。しかしながら、FHIR 仕様の試用期間中は、発見された仕様の問題に対応するために、HL7 はここに記載されている範囲以外の変更を行うことがあります。アプリケーションは、試用期間中おけるこの状況を管理するために、リソース・タグを使用することができます。

There is no explicit version marker in the resource content. Once normative, subsequent versions of this specification may introduce new elements and/or content at any point in the resource contents, but the path and meaning of existing data elements will not be changed. Any value set or code list may be revised to include additional cods

リソースのコンテンツには明示的にバージョンを示す印は一切ありません。一旦正式仕様になった後、FHIR のその後のバージョンで、新しいエレメントやコンテンツは、リソースのコンテンツに随時追加される可能性がありますが、既存のデータ・エレメントのパスや意味は変化することはありません。バリュー集合やコード・リストは、新しいコードを追加される形で更新されます。

Each binding to a value set or code system indicates whether the value list automatically grows as new codes are defined, whether the list may be extended in future versions of the specification, or whether the list cannot be changed at all in future versions.

バリュー集合やコード体系へのバインディングでは、それぞれ、新しいコードが定義されることで自動的にバリュー・リストが大きくなるかどうか、リストが将来の FHIR 仕様で拡張されることがあるか、あるいは将来の FHIR 仕様でリストが変化することがないかどうかが示されます。

The conformance layer (Conformance and Profile) have mandatory properties declaring the FHIR specification version, and these may be used to determine which version of FHIR an implementation is using.

コンフォーマンス・レイヤー（コンフォーマンスとプロファイル）には、FHIR 仕様のバージョンを宣言する必須のプロパティがあり、それを使って、実装システムが使用している FHIR のバージョンを決定できます。

In a typical scenario, mixed versions may need to exist, so applications SHOULD ignore elements that they do not recognize unless they are extensions with a isModifier element with value="true". However, in a healthcare context, many application vendors are unwilling to consider this approach because of concerns about clinical risk or technical limitations in their software (i.e. schema based processing). Applications are not required to ignore unknown elements, but must declare whether they will do so in their conformance statements using the acceptUnknown element.

典型的なシナリオでは、おそらくバージョンの混在は避けられないので、アプリケーションは、isModifierエレメントが "true" に設定されているエクステンション以外は、自身が認識できないエレメントを無視しなければなりません。しかしながら、医療のコンテキストでは、多くのベンダーが、医療上のリスクやアプリケーションの技術的制約（スキーマに基づく処理など）によって、この手法をとることを躊躇しています。アプリケーションは、未知のエレメントを無視する必要はありませんが、無視するかどうかを acceptUnknown エレメントを用いてコンフォーマンス宣言で、宣言しなければなりません。

Additional discussion on interversioning issues can be found here: http://wiki.hl7.org/index.php?title=FHIR_interversion_compatibility.

バージョン間の互換性の問題についての、更なる議論は以下で行われています：http://wiki.hl7.org/index.php?title=FHIR_interversion_compatibility

Further Information 「さらにくわしく知るには」1.10.0.4.1

Additional documentation.

以下のドキュメントを参照してください

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