1.2 リソースに関する諸定義（§1.2）

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

何らかの既知の識別情報で特定する事ができる
この仕様で定義されているリソース・タイプのいずれかに属している
リソース定義に記述されている一連の構造化されたデータ要素を含んでいる
リソースのコンテンツについての人間が読むことのできる XHTML 表現を含んでいる
時間の経過とともに変化しうる

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

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

リソースのコンテンツ（§1.2.1）

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

規定の基本データ要素
拡張部分（オプション）− 実装毎に追加される追加データ要素（"Extensibility"を参照）
人間が読むことを意図したリソースの叙述的記載（"Narrative"を参照）
内包リソース − 独立した個別のＩＤを持たないため、情報交換の都合上、リソースに内包されたリソース（後述）
メタデータ − リソースのコンテンツ・モデルに含まれない、リソースに関する重要な情報

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

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

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

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

リソースのメタデータ（§1.2.2）

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

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

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

リソースのバンドル（§1.2.3）

複数のリソースを取りまとめてひとつのインスタンスにするのはよく行われる操作です。FHIR ではこれをリソースを「バンドルする」（bundling）と呼びます。リソースのバンドルに含まれるのは、単にリソース本体への参照のリストではなく、リソースのコンテンツ全てが含まれます。リソースのバンドルにはいろいろな用途がありますが、その一部を挙げると以下の通りです：

サーバーの操作の一部として、ある条件に合致するリソースの集合を返すとき
サーバーの履歴確認操作の一部として、リソースの今までの一連のバージョンを返すとき
ひとまとまりのリソースを格納するとき
メッセージ交換の一部として、リソースの集合を渡すとき
あるリソースに内包された一群のリソースを、医療上意味のある塊（例：診療文書）として独立で交換あるいは永続的に保存可能にするとき

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

コンフォーマンス（§1.2.4）

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

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

スキーマ＆スキーマトロン
参照プラットフォーム
TODO：RDF/OWL 等

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

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

カーディナリティ（§1.2.5）

リソースの要素のカーディナリティとは、ある要素が実際のリソースの中に出てくる数の上限です。空の要素が出てくることは許されません。出てくる時には、属性の値か、子要素か、拡張要素を持たなければなりません。

Must-Understand（§1.2.5.1）

Must-Understand は、ある要素が、この仕様か、または拡張を定義しているプロファイルで、リソースの基本コンテンツとして定義されている場合に指定される属性です。ある要素が、その値によって他の要素やリソースの解釈を左右する場合には、"mustUnderstand=true" と指定されます。"mustUnderstand=true" と指定される要素の典型例は、"status"、"active" あるいは "certainty" といった要素です。要素の使用方法がリソース・プロファイルに記述されている時には、mustUnserstand の値を変更することはできません。

一般的に、"mustUnderstand=true" と指定された要素は、確実に処理するために最小のカーディナリティとして 1 を持ちます。そのような要素の値は、明示的にリソース中で指定されるか、コンテクストから既知でなければ、リソースを適切に処理できません。最小のカーディナリティに関わらず、リソースを生成する実装システムでは mustUnderstand の要素に適切な値が与えられるようにしなければなりません。mustUnderstand の要素は、リソースの叙述部における要約に反映されなければなりません。

リソースを処理する実装システムは、リソースを処理するにあたって、この要素の与える影響を判別しなければなりません。実装システムは、要素の値の全てに対し意味のある処理として "support" する必要はありません。実装の対応範囲外である値は無視することでも、この要件は達成されます。（例えば、アプリケーションは reliability != "ok" とされた所見を受け付けないかもしれません。）別のやり方として実装システム間の調整として、実装環境によって、そのような値が起こらないようにすることもできます。しかしながら、そのような場合でも、アプリケーションは常に、この要素の値を確認しなければなりません。

Must-support（§1.2.5.2）

リソースの要素を Must-Support と指定するのは、リソースを生成する、または取り込む実装システムが、この要素を意味のある処理として "support" する必要があるということです。これが正確に何を意味するのかは、FHIR の仕様の内部では、記述したり、明確にしたりすることはできません。

このため、FHIR の仕様自体では、どの要素も must-support とは指定しません。この指定が行われるのは、リソース・プロファイルの中で、プロファイルにて mustSupport=true と指定された要素についてです。この指定を行うプロファイルでは、同時に、正確にどのような種類の "support" が必要なのかも明らかにされます。なぜなら、その意味する所は多様だからです。

属性 mustSupport が指定された要素は、必ずしもリソースの「キー」要素（リソースの仕様に当たって重要な意味を持つ要素）とは限らず、リソースのキー要素が mustSupport とは限らないことに注意してください。しかしながら、mustUnderstand 要素については、その両方の命題が真である可能性が他の要素より高くなります。

Cardinality（§1.2.5.3）

FHIR で定義される全ての要素は、定義の一部として cardinality、最小限出てこなければならない数と最大限許される数とを持ちます。この数はインスタンス中に要素が出てきてよい数を指定します。この仕様では最小限 minimum としては常に 0 か 1 で、最大限 maximum は常に 1 か、制限なしを意味する * です。プロファイルにおいては、carnality の minimum にもmaximum にも、minimum <= maximum である限り、任意の整数を指定できます。

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

リソース間の参照（§1.2.6）

リソースの要素として定義されるものの中には他のリソースへの参照が含まれます。いろいろなリソースが網の目のように組み合わさって医療に関する情報を表現します。リソースの中に含まれる要素としてのリソースは、タイプ、URL、そしてテキストによる叙述で表されます。リソース参照のキー要素は url で、参照先のリソースは、その URL で特定され場所が示されます。リソース参照の実際の様子は以下に示す通りです。（リソースのコンテンツとしての実例は "XML Format" を参照してください。）

<[name] xmlns="http://hl7.org/fhir"> <type value="[code]"/> <url value="[uri]"/> <display value="[string]"/> </[name]>

用語のバインディング（§1.2.6.1）

パス

ResourceReference.type

詳細

全ての定義済みの Resource Type 名を取りうる

強度

complete/required

留意点：

リソースへの参照は、その要素が参照するリソースのタイプがリソース定義にて固定されているかいないかに関わらず、必ず、要素 type を指定しなければなりません。
要素 url では、絶対 URL を使った参照は確実で実装規模の拡大が容易な手法で、クラウド／ウェブのコンテキストに向きますが、一方、相対 URL を使った参照は柔軟な手法で、閉じた情報利用環境でのやりとりに適しています。詳細については実装上の問題点を参照してください。）
絶対 URL は、必ずしも FHIR RESTful サーバーを参照する必要はありませんが、参照することが推奨されています。URL の末尾が "/[type]/@[id]" あるいは "/[type]/@[id]/history/@[id]" の形式に従っている場合は、URL は FHIR RESTful サーバーを参照しているものと解釈しなければなりません。
URL は常にアルファペットの大文字小文字を区別するものとして扱われ、小文字の使用が推奨されます。
要素 display は、参照されているリソースの Resource.text と同じ内容ではありません。この要素の役割は、どのリソースが参照されているかを示すことで、そのリソースの内容を記述することではありません。

制約：

リソースが内包されている時には、url は相対 URL で指定しなければなりません (xpath: not(starts-with(f:url/@value, '#')) or exists(ancestor::a:content/f:*/f:contained/f:*[local-name(.)=current()/f:type/@value and @id=substring-after(current()/f:url/@value, '#')]|/f:*/f:contained/f:*[local-name(.)=current()/f:type/@value and @id=substring-after(current()/f:url/@value, '#')]))
url が指定された時には type の値が必要です (xpath: exists(f:type) or not(exists(f:url)))

FHIR RESTful サーバー上の "context" という名前の要素に含まれる patient "034AB16" に対する相対参照：

"profile" という名の要素の中の resource profile に対する絶対参照：

注意：HL7 はまだこのようなプロファイルのレジストリを構築していませんし、そのための URL も決定していません。

人間が読んで参照先のリソースを特定できるように、短い表示用のテキストをつけることができます：

参照を実際のリソースに結びつけられなかったシステムは、このテキストを問題解決のために使うことができます。

内包されたリソース（§1.2.6.2）

状況によっては、リソース参照で指示されたコンテンツが、そのリソース参照を含むリソースの外部には独立して存在せず、それ単独では個別に指定できず、独立した取扱うための範囲も持たない場合があります。そのような状況として、よく見られるのは、元となったデータを、中間の操作者、例えばミドルウェアがが取りまとめた際に起こります。リソースのインスタンスを組み立てる際に利用可能なデータに、記録のキー情報や絶対 ID の情報が含まれていない場合には、リソースの ID に関する属性を構築できず、恣意的な ID 情報を付加することはできるとしても、そのリソースを参照するリソースのコンテクストの外では、やりとりできなくなってしまいます。

このような状況では、参照先のリソースはリソース参照に内包する形で置かれます。この方法は、コンテンツが個別に適切な ID を持つことができる場合には、決して取ってはいけません。なぜなら一度失われた ID 情報を再現するのは非常に難しい（そしてコンテクストに依存する）からです。

内包されたリソースの例：

JSON での同じ例：

{ "Document" : { "extension" : { ... }, "text" : { .. }, "contained: [ {"Organization" : { "_id" : "org1", .. whatever information is available ... }} ] "information: { ... other attributes ... "custodian" : { "type" : { "value" : "Organization" }, "url" : { "value" : "#org1" } } ... other attributes ... } }}

このような場合は冗長ではありますが、まず URL を解釈し、それに従ってアクセスするという、一貫したシンプルな方法でリソース参照の処理が行えるよう、要素 type と url は常に必要です。

内包されたリソースの使い方と解釈に関していくつかの注意事項があります：

内包されたリソースは、親となるリソースと同じ内部 ID の参照範囲を持ちます。
内包されたリソースは、親となるリソースからコンテクストを「継承」します。たとえば、親のリソースがある "subject" を持っていた場合に、内包されたリソースも要素 subject が定義されていても、何の subject も指定されていない時、処理するアプリケーションは、親リソースと同じ subject であると推論する場合があります。しかしながら、このような推論はある決まった状況に固有のものであることに注意してください。たとえば、親リソースと内包されたリソースの間で要素 "subject" の意味するところは同じであるといったルールはありません。

バージョン間の互換性（§1.2.7）

XML には明示的なバージョン間の差異を示すマーカーはありません。この仕様の後のバージョンで、コンテンツ・モデルに新しい要素が追加されることはいつでも起こりえますが、現在存在する要素のパスや意味が変わることはありません。

コンフォーマンス・レイヤー（Conformance および Profile）には、FHIR 仕様のバージョンを宣言する必須の属性がありますので、これらをバージョンの差異を考慮した実装に利用することができます。

通常のシナリオでは、バージョンの混在は許容されるべきで、アプリケーションは、要素に "mustUnderstand" 属性が true に設定された仕様拡張でない限り、認識できない要素は無視しなければなりません。しかしながら医療のコンテキストでは、多くのベンダーが、医療上のリスクの懸念やソフトウェアの技術的制限（例えば、スキーマに基づく処理）から、この方法をとるのは消極的です。アプリケーションは未知の要素を無視する必要はありませんが、コンフォーマンス宣言の acceptUnknown 要素で、未知の要素を無視するかどうかを宣言しなければなりません。

注意：FHIR は、正式な HL7 標準として投票される以前の、現在開発中のドラフト仕様です。

実装者がここで定義されている内容での試験実装を行うことは歓迎されていますが、内容が事前の通知無しで変更される可能性があることを明記して下さい。