1.4 データタイプ（§1.4）

FHIR の仕様では、リソースの要素として使われる一連のデータタイプを定義しています。データタイプには、XML スキーマから取り入れた Primitve データタイプとその Simple バリエーションと、複数の要素のよく使われる組み合わせである Complex データタイプが含まれます。

凡例： オレンジ：カテゴリー、グレー：グループ、水色：データタイプ、黄色：制約

W3C スキーマ形式のデータタイプの定義が用意されています。

Primitive データタイプ （§1.4.1）

下表は、FHIR 全体を通じて使われる Primitive データタイプとその Simple 制約のまとめです。これらのデータタイプの取りうる値は W3C スキーマ仕様のパート 2 の記述に基づきますが、太字で示した追加の制約条件が加わっています。

Primitive データタイプ

Simple 制約

Simple 制約を含む Primitive データタイプは、XML 要素として表現され、データの値は要素のテキストに格納されます。リソースのデータ要素としての XML タグ名（JSON プロパティ名）は、リソース定義でデータタイプが使用される所で定義されます。XML 要素には id 属性をつけることができます。JSON では、データタイプはオプジェクトとして表現され、id 属性のための "_id" というプロパティと、値を格納する "value" というプロパティを持ちます。

Complex データタイプ（§1.4.2）

Complex データタイプは、子要素を持つ XML 要素で、各子要素にはデータタイプの要素として定義された名前がついています。リソースのデータ要素としての XML タグ名（JSON プロパティ名）は、リソース定義でデータタイプが使用される所で定義されます。XML 要素には id 属性をつけることができます。JSON では、データタイプは XML 要素と同じ名前のプロパティを持つオブジェクトとして表現されます。JSON による表現は、どのデータタイプについてもほとんど同じなので、最初の例だけに JSON 表現が併記されます。

Complex データタイプには、プロファイルが適用されることがあります。プロファイルは、データタイプの各要素が値を持つ必要があるか、どのような値を持てるかについての一連の規則を決めるものです。

Attachment（§1.4.3）

Attachment データタイプは、別フォーマットで定義された追加データである、添付データを格納または参照します。最も一般的な使い方は画像や、PDF などの形式のレポートを取り込むことですが、MIME 形式のデータならば、どのようなデータにも使えます。

用語のバインディング

要素 contentType の値は必ず指定しなければなりません。その値には、文字セットの情報やその他の MIME タイプの拡張情報も必要に応じて含めることができます。文字セットが contentType で指定されていない時の正しい動作は定義されていませんが、メディアタイプによっては、デフォルトの文字セットが定まっていたり、コンテンツを調べることで判明する場合もあります。

Attachment のコンテンツの本体については、data 要素で直接伝達することも、url 要素で参照情報を渡すこともできます。重複して伝達する時には、data 要素に含まれるものと url 要素で指されるものは、全く同一でなければなりません。同じ url 要素の値が、後に別の内容を指すよう再利用されることは許されません。（つまり、特定のバージョンを指す値であることが必要です。）指定された url の値は、参照結果として実際のデータを指すものでなければなりません。このような条件を満たす URI としては、cid: 等があげられます。

アプリケーションが url の指すコンテンツが変更されていないことを検証するために、ハッシュ値を hush 要素に入れておくことができます。

実際の使用において Attachment の繰り返し数が >1 になることは少なくありません。正当な繰り返しの使い方の例としては、全く同じコンテンツを異なる MIME タイプや言語で添付する場合があります。このタイプを使用するリソースの要素や拡張では、繰り返しが意味することについての解説を定義に含めなければなりません。Attachment のコンテンツの言語は xml:lang 属性によって示すことができます。

使用上の注意

もし data も url も指定されない場合は、言及されている理由により、該当する mimeType や xml:lang のコンテンツがないことを意味していると理解すべきです。

しばしば、使用のコンテキストによって、利用可能な添付ファイル（つまり利用可能な MIME タイプ）についてのルールが決まることがあります。

Coding（§1.4.4）

Coding データタイプは、列挙型、コードリスト、SNOMED-CT や LOINC といった完全な用語集あるいは具体的なオントロジー（概念体系）といった、定義済みの「コード体系」から選ばれた、あるシンボルで表される定義済みの概念を表現します。

要素 system は、要素 code の定義が含まれる、列挙型、用語集またはオントロジーを指す URI です。この URI には OID（uri:oid:）や UUID（urn:uuid:）や Named System List で定義された URI やコード体系の定義を参照する URI や、その他のコード定義をユニークに特定する URI が指定可能です。ここで使われる OID や UUID にはHL7 OID 登録リストに登録済みのものを使うことができ、またコンテンツが施設の境界をまたがって使われる時には、登録済みのものを使うべきです。

code が与えられる時には、コード体系 system の形式に沿った正しい符号でなければなりません。コード体系によっては、SNOMED-CT のように、code の値が、複数のコードが組合わさった表現になっていることがあります。コード体系に別段の指定がない時には code は大文字小文字が区別されることに注意が必要です。要素 display は、コード体系 system で定義される code の意味を表すテキストで、アプリケーションがコード体系 system を知らない場合にコードの意味を表示するのに使えます。

system が与えられ、code が与えられない場合には、コード体系 system には code に入れるべき適切なコードが存在しないという意味になります。

もし、ふたつの Coding データタイプの値が、同じ system と code を持つ場合は、それらは全く同じ意味を持つことになります。もし、あるコード体系が改版によってコードの意味を再定義した時には、それぞれの版は別の system の値を持たなければなりません。system と code のいずれかが異なる場合には、そのふたつの関係は、コード体系の定義を付き合わせるか、なんらかの利用可能なマッピングによってのみ決定されます。

あるコード体系についての正しい system の値を知るには、以下の情報源があります：

• Named Systems List セクション
• HL7 OID 登録リスト
• コード体系の仕様文書
• コード体系の発行者に相談する
• HL7 vocabulary メーリングリストで質問する

使用上の注意

通常、使用のコンテキスト（リソースまたは適用されるプロファイルで定義されます）によって、特定のコンテキストでどのコードやコード体系が認められるか、あるいは必要とされるかについての決まりが、要素の値集合へのバインディングによって作られます。

Coding と CodeableConcept の使い分け（§1.4.4.1）

Coding データタイプはコード体系のなかのコードを単純に直接指定するものです。実用の面では、このような単純な指定を使用するのはとても困難です。システムがテキストに対応するコードを見つけられない場合や、ふたつの異なるシステムが異なる用語体系や異なる複数のコードとテキストの組み合わせを使用している時には、Coding データタイプでは、このような状況をうまく処理するのに十分な情報を提供できません。このような状況は極めて一般的なので、複数の Coding データタイプとひとつのテキスト表記を要素に持つことのできる CodeableConcept データタイプが定義されています。リソースではわずかな例外を除いて、単純な Coding データタイプより CodeableConcept データタイプが選ばれます。Coding データタイプが別途設けられているのは、主にプロファイル中で使用するためで、ユースケースが明示されるプロファイルでは用途の広い CodeableConcept より構造をうまく定義できるからです。

CodeableConcept（§1.4.5）

CodeableConcept データタイプは、通常ひとつまたは複数の用語体系や概念体系の形式に沿って値が指定される一方で、テキストの値も受け入れるデータフィールドを表現します。これは医療データでよく見られるパターンです。

それぞれの coding 要素は、列挙型、コードリスト、SNOMED-CT や LOINC といった完全な用語集あるいは具体的なオントロジー（概念体系）といった、定義済みの「コード体系」から選ばれた、あるシンボルで表される定義済みの概念を表現します。その概念は、異なるコード体系から複数回コード化することができます。（あるいは、SNOMED-CT のように、コードの複数指定が可能な場合は、同じコード体系から複数回コード化することもできます。）それぞれの Coding 要素の表す意味の範囲は、元になっているコードの定義の違いにより微妙に異なるかもしれません。CodeableConcept データタイプにおける Coding 要素の順番は定義されていません。

Coding 要素の有無に関わらず、ユーザーが入力または選択した表現である text 要素が、ユーザーの意図した意味または概念を最も正確に表したものとされます。しばしば text 要素は、いずれかの Coding 要素の display 要素と一致します。Coding のうちのひとつを primary 要素で、ユーザーが直接選んだものとして指定できます。指定する際には primary 要素の値は、xml:id で、Coding 要素のうちのひとつの id 属性の値と一致しなければなりません。

使用上の注意

• primary 要素の値を指定する時には、coding 要素のいずれかひとつを指さなければなりません。 (xpath: not(exists(f:primary)) or count(f:coding[@id=current()/f:primary/@value])=1)

通常、使用のコンテキスト（リソースまたは適用されるプロファイルで定義されます）によって、特定のコンテキストでどのコードやコード体系が認められるか、あるいは必要とされるかについての決まりが、要素の値集合へのバインディングによって作られます。

Choice（§1.4.6）

公式なコード体系ではない、少数のコードの並びから選ばれたコードを表します。Choice データタイプは、痛みのスケールや、質問票や、公式に定義された評価指標などに使われます。選べるコードの選択肢は、予め決められた任意のスケールにより、順番を持つことができます。注意：選べるコードが、公式なコード体系のデータセットとして定義されていたり、そうでなくても用語集サーバーに格納されている場合は、Choice データタイプは適切なデータタイプではありません。

要素 code は、選択された値を表します。コードの選択肢は必ず与えられなければならず、value 属性にはそれぞれ少なくともひとつのコードが与えられる必要があります。選択されたコードは必ず選択肢のリストの中になければなりません。

要素 IsOrdered が true の時は、選択肢には固有の意味を持った順序があり、選択肢のリストは、このデータタイプのインスタンスで与えられた正しい順番で表示されなければなりません。

Quantity（§1.4.7）

測定された量（あるいは測定対象となりうる量）を表します。

用語のバインディング

要素 value には、量を表す数値が、精度の表現付きで入ります。要素 comparator が指定されない時には、要素 value は範囲を持たない一点を示す値（＝）を意味します。要素 comparator が指定された時には、必ずその意味を含んで解釈・表示しなければなりません。

要素 units は、何が計られたかを表す、値の表示に使う単位を指定します。要素 units で指定された単位は、さらに要素 code と要素 system を使って、単位を表すコードを指定することができます。（要素 system の詳細な使い方については、Coding データタイプを参照してください。）

要素 units の単位が UCUM で表現できる時に、要素 code を指定するならば、その値は UCUM のコードでなければなりません。要素 code に UCUM のコードが指定されている時には、Quantity データタイプで表される値の間で、正規の値として比較を行うことができます。要素 units の中には正しい UCLM の単位名が入っていることが多いですが、それは保証されないことに注意してください。

Quantity の定義済みの派生型（§1.4.7.1）

リソース・コンテンツ・モデルで使われているデータタイプの中には、実際には Quantity データタイプにいくつかの制約を追加した派生型があります。

Range（§1.4.8）

下限値と上限値で定義される大小を持つ Quantity データタイプの値の集合。

Range データタイプは、取りうる値の集合を指定します。通常は、その範囲のひとつの値が適用されます。（例：患者に 2 錠から 4 錠の間で投与）Range データタイプは指示によく使われます。

要素 low と high との要素 units と system は一致しなければなりません。要素 low と high のいずれかが欠落している場合は、下限または上限が知られていないということで、どちらもその方向には限界がないということになります。

要素 low と high では要素 comparator を指定してはいけません。Quantity データタイプで要素 comparator を使って表すような測定値に Range データタイプを使ってはいけません。

要素 low と high の値は指定の範囲に含まれ、その精度はどこまでも高いものとして認識されます。例えば 1.5 から 2.5 までの Range は 1.50 と 2.50 を含みますが、1.49 や 2.51 は含みません。

使用上の注意

• Range データタイプに使用する時には、Quantity データタイプは comparator を指定してはいけません。 (xpath: not(exists(f:low/f:comparator) or exists(f:high/f:comparator)))

Ratio（§1.4.9）

分子と分母に当たるふたつの Quantity データタイプの値の比。

分子と分母の約分は自動的には行われません。Ratio データタイプは、力価（例 "1:128"）や検査で使われる実際の比率を表現するもので単なる「数字の組み合わせ」、例えば血圧の測定結果（例 "120/60"）は、Ratio データタイプの対象ではありません。また、Ratio データタイプは、分子と分母を約分することがない状況で使うもので、そのもっともよくある例は、単位当たりの値段を表すもので、その場合は分子が通貨（例：$50/10）になります。

使用上の注意

使用するコンテキストによって、分子と分母に特定の種類の Quantity データタイプが必要になることがあります。

Period（§1.4.10）

開始時点と終了時点で定義される期間。

Period データタイプは時間の範囲を指定します。指定された時間の範囲すべてが当てはまるのか（例：「ある患者がこの期間入院していた」）あるいは指定された範囲の一時点のみあてはまるのか（例：「2 時から 4 時までの間に患者に投与」）は使用されるコンテキストに依存します。

もし、要素 start が指定されない場合は、期間の開始時点は不明ということになります。もし、要素 end が指定されない場合は、期間は継続中ということにります。

要素 start と end の値の解釈は、該当する日時は全て含むことになります。例えば 2011-05-23 と 2011-05-27 の間の Period データタイプの値は、2011 年 5 月 23 日の全ての時間と、2011 年 5 月 27 日の最後の時間まで含まれることになります。

Identifier（§1.4.11）

FHIR の規約の外部で用いられる識別子、ＩＤ。FHIR の取り決めの範囲外なので、これらのＩＤは、人為的またはシステム上のプロセスやエラーのため、変更になったり、廃止になることがあります。

用語のバインディング

要素 system は URI を用いて、ＩＤがどのように定義されているか（すなわち、一義性を保証されているか）を示します。具体的には、ＩＤを発行するアプリケーション、値の集合やＩＤに関する認知されている標準／仕様、あるいはその他のＩＤの一義性を保証する方法です。要素 id は system で指定される範囲で重複のない値であることが必要で、使われている全ての場所で一貫した意味をもたなければなりません。ＩＤはつねに大文字小文字が区別されます。

FHIR では、いくつかの有用な URI を直接定義しています。OID（urn:oid:）と UUID（urn:uuid:）は、HL7 OID registry に登録されていることがありますし、もし施設の境界を越えて使用するのであれば登録すべきです。ＩＤ自体が元々グローバルに一義性を持つ（例えば OID や UUID やローカル部分を持たない URI）のであれば、system の値は urn:ietf:rfc:3986 となり、URI は id に入ります。

場合によっては、system が不明で id のみが与えられる（例：バーコードを読み取る単純な装置）ことや、system が暗黙的に知られる（限定されたコンテキストでの単純な情報交換、しばしばバーコードリーダーによる）こともあります。このような場合は、システムがコンテキストを確実に類推できない限りは、有用なマッチングは実行できません。より広いコンテキストでの情報共有が次第におこることがしばしばあるので、実装を長期間の仕様に耐えるものにするために、このような利用方法は極力避けるべきです。

要素 assigner は、ＩＤを割り当てた登録機関、行政区画、施設などを表します。

HumanName（§1.4.12）

テキスト表記、用途および構成要素の情報を含む、人の名前。

一旦伝えられた名前でも、変更になったり、取り消されたりすることがあります。ひとりの人が、違うコンテキストでは別の名前を持つことがあります。名前は、いくつかの部分に分けることができ、それぞれの部分の重要性はコンテキストによって異なり、また、必ずしも構成する部分に分けることが大事とは限りません。個々人の名前の、それぞれの部分には、暗黙的な意味を持つ場合も持たない場合もあります。様々な文化で名前の構成要素には違った重み付けがなされていて、システムが名前の構成要素の取扱いにどれだけ配慮すべきかは世界の各所で大きく異なります。

用語のバインディング

要素 text は、名前全体をどのように表示すべきかを指定します。名前の構成要素を指定する代わりに要素 text だけ指定することもできますし、名前の構成要素と一緒に指定することもできます。要素 given に指定される複数の名前の構成要素の順番には意味があり、その順番は保持しなければなりません。姓と名の順序は文化や、使用するコンテキストによります。

Address（§1.4.13）

郵便の住所。世界中にはさまざまな住所表記があります。郵便の住所はしばしば特定の患者や人に面会を求めるための場所を記録するために用いられます。

要素 text は、表示の時に使う住所表記全体を指定します。住所の構成要素を指定する代わりに要素 text だけ指定することもできますし、住所の構成要素と一緒に指定することもできます。

制約

Contact（§1.4.14）

電話や電子メール等を含む、あらゆる種類の通信技術を介した、個人や組織への連絡先。

用語のバインディング

電話やFAXやそれらに類する連絡先を格納する時は、値は ITU-T E.123 に準じた適切な形式の電話番号にすべきですが、過去のデータ資産や記録手段の制約から対応できないことが少なくありません。

制約

• 要素 value が値を持つ場合は要素 system が必須です。 (xpath: not(exists(f:value)) or exists(f:system))

Schedule（§1.4.15）

繰り返すこともあるイベントの予定を表します。Schedule データタイプは実際に出来事が生じた時ではなく、生じると予想された、あるいは予定された時を表します。Schedule データタイプは、イベントが起こる時を表す Period データタイプの要素 event のリストか、要素 event はひとつで繰り返し条件を表す要素 repeat がつくか、要素 event を持たず要素 repeat のみをもつかのいずれかです。

注記：このデータタイプの拡張案として、要素 event のそれぞれに要素 repeat を繰り返すことが考えられます。表現力が向上する一方でより複雑になりますが、この拡張は有用でしょうか？

用語のバインディング

要素 event を指定する場合には、少なくとも子要素 low は指定する必要があります。子要素 high を指定しない場合は、イベントは医学的に妥当な、ある限られた、しかし特定されない期間継続することを意味します。

Schedule データタイプが、要素 repeat を持つ場合は、繰り返しが、指定された期間ごとに、またはある実世界のイベントに関連して、与えられた回数起こることを示します。また、繰り返しイベントの終了は、繰り返すべき回数または予定を終了する日時のどちらかで指定できます。もし終了条件が指定されない場合は、他所で指定されるある条件で終了することになります。

制約

• 要素 repeat は、要素 event が存在しないか、ひとつだけの時です。 (xpath: not(exists(f:repeat)) or count(f:event)<2)
• 要素 repeat について、子要素 count と子要素 end は同時には存在できません。 (xpath on /repeat: not(exists(f:count) and exists(f:end)))
• 要素 repeat について、子要素 frequency と子要素 when のどちらかひとつだけが常に必要です。 (xpath on /repeat: exists(f:frequency) != exists(f:when))
• 要素 repeat について、子要素 duration は正の値でなければなりません。 (xpath on /repeat/duration: @value > 0 or not(@value))

その他のデータタイプ（§1.4.16）

以下のデータタイプは、この仕様の別の場所で記述されています。

• Resource − 全てのリソースの抽象基本クラス
• ResourceReference − あるリソースから別のリソースへの参照
• Extension − リソースの拡張情報を伝えるのに使われます
• Narrative − リソースのコンテンツを人間が読んで理解するための表現を伝えます