Home ＞ Documentation ＞ Data Types [datatypes]

1.13.0 データ型

FHIR仕様では、リソースのエレメントで使用される、いろいろなデータ型を定義しています。FHIR 仕様で用いられるデータ型には、XMLスキーマから取り入れた単純／プリミティブ型と、繰り返し使用されるエレメントの組み合わせパターンである複合型の 2 種類があります。このページでは、このような FHIR 仕様のデータ型について説明します。サンプルデータ一覧 、 公式定義一覧表と他の標準仕様とのマッピング も合わせて参照してください。

データ型の定義はW3C形式のスキーマ として入手可能です。

1.13.0.1 プリミティブ型

次の表は、FHIR 仕様の全般を通して使用される、プリミティブ型と、それらに単純な制約を加えた派生データ型をまとめたものです。プリミティブ型は、全てのデータ型と同様にエクステンションを持ちますが、それ以外の下位プロパティを持たないデータ型です。プリミティブ型は、原則としてW3Cスキーマ（1.0）仕様パート 2と同じ値の取りうる範囲を持ちますが、いくつかのケースでは、FHIR 仕様独自の制約が追加されていて、それらは下表では太字で表現されています。

上記のような値を保持することに加えて、これらのプリミティブ型にも、リソースの他のエレメントと同様に、ID（例えば、xml:id）を付加したり、エクステンションを持たせることができます。value 要素にも、すべての要素に共通のルールが適用され、省略可能であり、 存在しない可能性があることに注意してください。例えば、プリミティブ型の要素が、value を持たず、かわりにデータが存在しない理由を表現するエクステンションを持つこともあり得ます。

XML 表記では、これらのデータ型は、value アトリビュートにデータ型で定義された値を持つ XML エレメントとして表現されます。エレメントの名称は、データ型のインスタンスが出現した場所で定義されます。データ型を表現する XML エレメントはid アトリビュートおよび「extension」という名前の（エクステンションを表現する）下位エレメントを持つことができます。XML スキーマでの定義に従い、value アトリビュート内の先頭と末尾の空白は、次に挙げるデータ型、boolean、integer、decimal、base64Binary、instant、uri、date、dateTime、kid、そして uri のそれぞれでは無視されます。このことから、 XML で表現された FHIR インスタンスを読み込む際には、スキーマを認識する XML ライブラリと、スキーマを認識しない XML ライブラリとでは、アトリビュートの値が食い違うということに注意してください。このため、ここに挙げたデータ型の value アトリビュートには、先頭と末尾に空白文字を持たせては＜なりません＞。string 型の場合は、実際にコンテンツの一部である場合にのみ、先頭と末尾に空白文字を持たせなければなりません。

JSON 表記では、これらのデータ型は、それらを含むオブジェクトの単純なプロパティとして表現されます。プロパティの名前は、データ型のインスタンスが出現するところで定義されます。データ型が idプロパティや extension を持つのは、XML 表記と同様です。id プロパティや extension の具体的な表現方法についてはJSON によるリソース記法 を参照してください。JSON 表記では空白文字はつねに重要な意味を持ちます。string 型以外のプリミティブ型では、先頭および末尾に空白文字を持たせては＜いけません＞。

1.13.0.2 複合型

複合型は、データ型の定義に挙げられたエレメントと同じ名前の下位エレメントを持つ XMLエレメントとして表現されます。エレメントの名前は、データ型が使用される場所で定義されます。どの XML エレメントも id アトリビュートを持つことができます。JSON 表記では、データ型は、XML エレメントと同じ名前のプロパティを有するオブジェクトによって表現されます。JSON 表記は、いずれもほとんど同じなので、複合型の最初の例にのみ 、XML 表記に加えて、JSON 表記が付属しています。

複合型には「プロファイル」を設定することができます。プロファイルは、エレメントが値を持た＜なければならない＞かどうか、どんな値を持つことが可能かについての一連の規則を定めます。

複合型のUML図

1.13.0.3 Attachment

参考例 、 公式定義およびマッピングも参照してください 。

このデータ型は、FHIR 仕様の外で定義される形式の添付ファイルを格納するかリファレンス.するためのものです。このデータ型の最も一般的な使い方は、PDF のようなレポート形式で、画像やレポートを格納することです。しかし、それ以外でも MIMEタイプを持っているどんなデータでも用いることができます。

1.13.0.3.1 用語のバインディング

ContentType エレメントは常に値を持た＜なければなりません＞。必要に応じて、文字セット情報やその他のMIMEタイプの拡張子を含めることができます。contentTypeで文字セットが設定されていない場合の、正しい動作は定義されていませんが、メディアタイプによっては、デフォルトの文字セットが定義されていたり、コンテンツを調べることにより適切な文字セットを決定することができるかもしれません。

添付ファイルの実際のコンテンツは、直接data エレメントを使って転送するか、URLリファレンスを伝達することができます。両方が含まれる場合、リファレンスは data に格納されているのと同一のコンテンツを指してい＜なければなりません＞。リファレンスは、くりかえし利用されて複数の異なるコンテンツを指すことはありません。（したがって、バージョン指定のリファレンスが用いられます。）URLリファレンスは、必ず実際に存在するコンテンツの場所に行き当たら＜なければなりません＞。cid: のようないくつかのURI はこの要件を満たしています。URLが相対リファレンスである場合は、リソースへのリファレンス同じ方法で解釈されます 。

hushは、アプリケーションが URL で返されるコンテンツが変更されていないことを確認できるように含まれています。

Attachment が用いられる時には、多くの場合、カーディナリティは 1 より大きくなります。Attachment の繰り返しの正しい使用法のひとつは、異なる MIME タイプや異なる言語で同じ内容を伝えることです。エレメントの繰り返しが意味するところについてのガイダンスは、このデータ型を元にしたリソースのエレメントまたはエクステンションの定義で明記され＜なければなりません＞。 language エレメントは、BCP 47で定義されたコードを用いて添付ファイルで用いられている言語を指定します。

{0}制約事項{/0}

dataとURLのどちらも与えられない場合は、指定されたmimeTypeや言語に合致するコンテンツが、宣言された理由によって、入手できないという表明として扱わなければなりません。

使用されるコンテキストによって、しばしば、使用することができる添付ファイルの種類（したがって、MIMEタイプの種類）が規定されることがあります。

Attachment は、以下の場所で使用されます： DiagnosticReport、Media、Observation、RelatedPerson、Patient および Practitioner

1.13.0.4 Coding

参考例、 公式定義、 マッピングも参照してください。

coding データ型は、あらかじめ定義された「コード体系」に含まれるシンボルとしての文字列を使用して定義された概念の表現です。くわしくはリソースにおけるコードを使用を参照してください。

coding データ型の伝える意味は、コードの定義に従います。systemは、省略可能なバージョンへのリファレンスと共に、コードの定義の出典を明示します。display は、コード体系の中で定義された人間に表示するためのテキストです。コードの定義通りの意味に何らの情報も追加しません。ValueSet は、コードがどのような選択肢から選ばれたのかというコンテキスト情報を伝達します。

systemは、codeが定義されているコード体系をリファレンスする URIです。 URI は以下のような値を取ります：

• 既知のコード体系のリストに定義済みの URI
• HL7のOIDレジストリに登録されているものを含む、OID (urn:oid:)またはUUID (urn:uuid:)
• ValueSetリソースの ValueSet.define.system の値として指定されたコード体系へのリファレンスも含む、コード体系の定義を直接リファレンスする URL
• または、その他どんな形でも、特定のコード体系の定義を一意に指定する URI

あるコード体系を表すために system に指定するべき値は、以下のリストの資料や手続きを順に適用することで決定できます。

• FHIR 仕様の既知のコード体系リストのセクション
• HL7のOIDレジストリ
• そのコー​​ド体系の関連文書
• そのコー​​ド体系の発行団体への問い合わせ
• HL7のボキャブラリー・メーリングリストでの相談

コー​​ド体系に加えて、そのバージョンを指定することもできます。コー​​ド体系に含まれるコードの意味が、リリース（訳注、バージョン）が異なっても一貫している場合、指定する必要はありません。コード体系に含まれるコードの定義が、バージョン間で一貫性を維持していないときは、バージョンを伝達し＜なければなりません＞。特定のコード体系の特定のバージョンが指定された ValueSet がリファレンスされている場合は、code の値が含まれるコード体系とそのバージョンは、ValueSet のものとっちし＜なければなりません＞。以下のコード体系では、常にバージョンを明記＜するべきである＞ことに注意してください。

• LOINC
• ICDの様々なバージョン
• SNOMED CTの各国独自のリリース（定義の一貫性が行政当局の間で異なったり、行政当局の中には、定義の一貫性について独自のルールを作る場合があります）

バージョン管理の詳細についてはValueSet リソースにおけるコード体系のバージョンについての議論を参照してください。

codeの値が与えられた場合には、systemで指定されたコード体系で定義された正当なシンボルで＜なければなりません。＞コード体系によっては、SNOMED CT のようにシンボルが事前に定義された別々のシンボルの組み合わせで構成されている（例えば、随意構成型のコード）場合があります。コー​​ド体系により特に指定されていない限り code の値は大文字と小文字が区別されることに注意してください。display は、system で指定されるコード体系で定義された、code に対応するテキスト表現で、system で指定されるコード体系に対応していないアプリケーションで code の表す意味を表示するのに使われます。

コード体系で、そのコードに複数の表示テキストが定義されている場合、そのうちのひとつだけを display に指定し＜なければなりません＞。コード体系によって推奨されている表示テキストがあれば、その推奨にしたがわ＜なければなりません＞。コード体系によっては、表示テキスト（例えばSNOMED CT 表現）を定義していない場合は、 display を設定することができず、コード表現に対応していないシステムでは、code の値の示す意味を利用できなくなります。

場合によっては、system が指定されず、code のみが指定されることもあります。コンテキストからコード体系を確実に同定することができない限り、実際の業務に関わる code の処理は一切行ってはいけません。結果的に当初の想定より広いコンテキストでの情報共有が行われる可能性が非常に高いので、このような運用は、できる限り避けるべきで、コード体系が不明な場合は code を業務に使用することはできません。

system が指定され、code が指定されていない場合、これは code に入れる適切なコードが system で指定されるコード体系に存在しないことを意味すると解釈されます。

2 つのコード表現が同じ system、version、code の値の組を共有している場合、その 2 つの表現は同じ意味を持つことになります。version が指定されていない場合や、system、 version、codeの 3 つのエレメントの値の組が異なる場合は、指定されている複数のコード表現の間の関係を知るには、（それぞれの）コード体系の定義を調べるか、何らかの形で提供されているマッピングを利用することしかできません。

ユーザがユーザインタフェース（例えば、選択リスト内の項目からの選択）を使って、code に入った値を選択した場合、そのコードは "primary" （一次選択）とマークすることができます。コードの解釈などを行う際には、"primary" とマークされたコード指定が優先的に使用されます。

コード表現がどのようなコンテキストで選択されたかをユーザあるいはシステムに示すために valueSet にリファレンスを指定することができます。コンテキストによっては、どのような候補であるコードの集合の中から選ばれたかが、code で指定された値の解釈に影響することがあります。valueSet で指定されるリファレンスは、system で指定されるコード体系への URI の代替としては受け入れられませんし、system に指定する URI の値として、コードの選択肢の集合へのリファレンスを指定＜してはなりません＞。（コードの選択肢の集合が、それ自体がコード体系としても成立する場合は、system に設定するべき値は、対応する ValueSet リソースにおいて ValueSet.define.system に設定する値と同一で、valueSet の値としては、その ValueSet リソースへの直接リファレンスを指定すべきです。

{0}制約事項{/0}

valueSet の値が指定されている場合、system の値として、コード体系への URIも指定し＜なければなりません＞。

特定のコンテキストでどのような code や system の値が指定可能か、あるいは指定しなければならないかは通常（リソース定義または対応するプロファイルに定義されている）使用のコンテキスト毎のルールによって、エレメントと可能なコードの選択肢集合がバインドされることによって決定されます。

Coding データ型は、以下でリソースで使用されます：CodeableConcept、Provenance、MessageHeader、SecurityEvent、Questionnaire、Composition、OperationOutcome、Conformance、Profile および ImagingStudy

デザインノート： FHIR 仕様では、コード化された値を表すための2種類のデータ型が定義されています：

• Coding：コード体系によって定義されたコードへの単純な直接リファレンス
• CodeableConcept： テキスト記述か Coding データ型のリスト、またはその両方で表される概念（例：複数のコード体系で定義された複数のコードへのリファレンスのリスト）

Codingデータ型は、あるコードのリストから単一のコードを選択する単純な場合に対応します。しかしこのデータ型はほとんど FHIR 仕様では使用されていません。 HL7 での長年の経験では、コード化された値を交換する一般的な状況では、システムは、いろいろな解釈から生じる複数のコードか、元のテキストか、その両方を交換できる必要があることがわかっているからです。

Codingデータ型がリソースの中で直接使われるのは、すべての利用者の間で確実に合意の取れたコードの値の選択肢の中から、確実にひとつのコードを選ぶ必要のある時に限られます。FHIR 仕様の用いられる、一般的な相互運用性のコンテキストでは、普通上記の条件は満たされないので、Coding データ型はもっぱら、より限定された特定のコンテキストでの使用を前提に定義されるエクステンションの中で用いられます。

1.13.0.5 CodeableConcept

参考例 、 公式定義、マッピングも参照してください 。

CodeableConcept データ型は、通常、単一または複数の用語やオントロジーをリファレンスすることにより示される値ですが、テキストによっても表現できるようになっているものです。これは医療データに共通のパターンです。

それぞれのCodingエレメントは、いずれもこのデータ型で伝達する概念のコード表現です。概念を別々のコード体系で何回もコード化することができます。（例えば SNOMED CT のような、いく通りも表現可能なコード体系であれば、ひとつのコード体系で何度でもコード化することもできます。）それぞれの coding エレメントは、用いられたコードの定義の違いにより、表現のさす意味範囲が異なることがあります。CodeableConcept内でcodingの指定される順序は意味を持ちません。CodeableConceptの典型的な使われ方は、ローカルのコードが割り当てられた概念を、単一または複数の LOINC や SNOMED CT といった一般的なコード体系でもコード化した上で送信することです。ローカルのコードを送信することは、デバッグやシステムの一貫性の監査の上で、有用かつ重要です。

cording 要素が存在するかどうかにかかわらず、 text こそが、ユーザによって入力または選択された概念の表現で、最も正確にユーザーまたは概念が意図する意味を表現しています。非常に多くの場合、text は coding エレメントのうちの、どれかひとつの display の値と一致します。coding エレメントのひとつだけ、primary のフラグを立てることができ、実際にユーザーが直接選択されたコードまたは概念であることを示します。coding エレメントのいずれも primary のしてマークされていない場合には、（存在する場合）text の値をこのデータ型の値として参照すべきです。

制約事項

• Inv-2: ユーザーが直接選択する coding はひとつに限られます。 (path: count(f:coding[f:primary/@value='true'])<1)

エレメントと取り得る値の集合とのバインディングの形での、特定のコンテキストにおいて、どのコード体系のどのコードが許容される、あるいは要求されるかは、普通、このデータ型が使用されるコンテキストによって決定されます。

CodeableConcept は以下に場所で使用されます： Provenance、Condition、CarePlan、Supply、Device、Order、Organization、Procedure、Substance、DiagnosticReport、Group、Medication、MessageHeader、ImmunizationRecommendation、DocumentManifest、MedicationDispense、MedicationPrescription、MedicationAdministration、Encounter、SecurityEvent、MedicationStatement、List、Questionnaire、Composition、DeviceObservationReport、Conformance、Media、FamilyHistory、Other、Location、Observation、DocumentReference、Immunization、RelatedPerson、Specimen、OrderResponse、Alert、Patient、Practitioner、AdverseReaction、 DiagnosticOrder

1.13.0.6 Quantity

参考例 、 公式定義およびマッピングも参照してください 。

測定可能な量（または原理的に測定可能な量）。

1.13.0.6.1 用語のバインディング

value には 、暗黙的な精度の指定を含む量を表す数値が格納されます。comparator が指定されていない場合は '=' と解釈され、上限や下限ではなく、値はその数値の表す一点です。comparatorエレメントは常に解釈の対象として考慮されます。

units には何を測定したのかを示す、表示に使用可能な単位が格納されます。units は、さらに code と system を使用して、いずれかの方式に従ってコード表現することができます。（systemエレメントの詳細な使用方法は Coding データ型を参照してください。 ）

units の値を UCUM でコード化することが可能な場合に、code を付加する場合には、コード体系として UCUM を使用＜してください＞。UCUM に含まれる単位が code で指定されている場合には、値は正規の単位に基づくものとして、量の間の比較のために単位を揃える変換をすることができる。units エレメントには、多くの場合、実際には UCUM に含まれる単位であるテキストが含まれますが、それだけでは、units エレメントで指定された単位が、実際に有効な UCUM に含まれる単位であると仮定することができないことに注意してください。

制約事項

• Inv-3：units に対応する code が指定された場合は、system も指定＜しなければならない。＞ (path: not(exists(f:code)) or exists(f:system))

このデータ型が使用されるコンテキストによって、しばしば、どのような量が想定され、したがって、どのような単位が使われるかが決定されます。さらに使用されるコンテキストからは、特定の system の中の特定の code で指定される単位が必要になる場合があります。あるいは使用されるコンテキストによって、取りうる value の値やその範囲 が制限されることもあります。

Quantity は、以下の場所で使用されます： Range、Ratio、SampledData、CarePlan、Supply、Substance、Group、Medication、MedicationDispense、MedicationPrescription、MedicationAdministration、MedicationStatement、Observation、Immunization および Specimen

1.13.0.6.2 Quantity データ型の定義済みの派生型

ここで挙げるリソースのコンテンツ・モデルに使用されているデータ型は、いくつかのルールが追加されているだけで、実際には Quantity データ型そのものです：

1.13.0.7 Range

参考例 、 公式定義およびマッピングも参照してください 。

下限値と上限値で指定される、順序をもった Quantity データ型で表現される量の集合。

Range データ型は、可能な値の集合を指定します。通常、ある範囲から 1 つの値だけが（たとえば「 2 錠から 4 錠までの範囲で患者に与える」）が適用されます。Range データ型は、通常、指示に使用されます。

low エレメントと high エレメントの間では units と code および system エレメントがそれぞれ一致してい＜なければなりません＞。low または high のいずれかのエレメントが欠落している場合、意味が下限または上限が未知のため、範囲として完全には閉じていないことになります。

low と high のいずれのエレメントのrange も指定できません。Range データ型は測定範囲外の測定結果を表すのに使ってはいけないことに注意してください。その代わりに comparator 要素を指定した Quantity データ型を使用してください。

low および high で指定される値はその値自身を含み、十分に高い精度を有すると仮定されます。例えば、範囲 1.5 〜 2.5 は、 1.50 と 2.50 は含みますが、1.49 と 2.51 は含まれません。

制約事項

• Inv-2： 存在する場合には low の値は high の値よりも小さく＜なくてはなりません＞。(path: not(exists(f:low/f:value/@value)) or not(exists(f:high/f:value/@value)) or (number(f:low/f:value/@value) <= number(f:high/f:value/@value)))
• Inv-3: Range データ型で使われる Quantity データ型には Comparator が指定されることはありません。 (path: not(exists(f:low/f:comparator) or exists(f:high/f:comparator)))

Range データ型は、以下の場所で使用されています： Group 、 FamilyHistory および Observation

1.13.0.8 Ratio

参考例 、 公式定義およびマッピングも参照してください 。

2 つの Quantity データ型の値で表現される、分子と分母の関係

分子と分母の約分は自動的には行われません。Ratio データ型は、力価（例えば、「1:128」）やその他、検体検査によって得られる実際に比になっている数値について用いられます。Ratio データ型は、血圧測定値（例えば「120/60」）のような単なる「構造化された数値」ではありません。また、Ratio データ型は、分子と分母が約分されない用途に用いられます。Ratio データ型の非常にありふれた例は、ユニット単価の表現で、分子がユニット数、分母が通貨（例えば、50/$10）のものです。

Ratio データ型の適切な使用方法は、分子と分母の両方を指定することです。しかし、エクステンションでその理由を説明した上での不完全に指定された Ratio データ型の存在を許容するために、分子と分母は必須になっていません。

制約事項

• Inv-1: 分子と分母は両方指定し＜なければなりません＞、そうでない場合は、両方とも指定＜してはいけません＞。(path: count(f:numerator) = count(f:denominator))

使用されるコンテキストによっては、分子や分母に、特定の形式の Quantity データ型が必要な場合があります。

Ratio データ型は以下の場所で使用されます： Substance、Medication、MedicationDispense、MedicationPrescription、MedicationAdministration、MedicationStatement および Observation

1.13.0.9 Period

参考例 、 公式定義およびマッピングも参照してください 。

開始と終了の日付または時刻によって定義される期間。

Period データ型は、時間の範囲を指定します。使用されるコンテキストによって、指定された範囲のすべて（例えば「患者がこの期間に病院の入院患者だった」）として解釈されるのか、またはその期間のある時点（例えば「2時から4時までの間に、患者に与える 」）として解釈されるのかが決定されます。

start エレメントが指定されない場合は、表現された期間の開始時点が既知ではないことになります。end エレメントが指定されない場合は、表現された期間が継続中であることを示します。

両端の日時には、指定された制度の日時に一致するすべての日付または時刻が含まれます。例えば、2011 年 5 月 23 日から 2011 年 5 月 27 日までと指定された Period データ型の値には 5 月 23 日のすべての時刻に続き 5 月 27 日の最後の時刻までが含まれます。

Period データ型は、以下で使用されています：Identifier、Provenance、CarePlan、Supply、Procedure、DiagnosticReport、MedicationDispense、MedicationPrescription、MedicationAdministration、Encounter、MedicationStatement、Composition、FamilyHistory、Observation、DocumentReference、Specimen および Practitioner

1.13.0.10 SampledData

参考例 、 公式定義およびマッピングも参照してください 。

医療デバイスによって収集された、上限値と下限値が指定された、一連の測定データ。データは多次元配列である可能性があります。

SampledData データ型は、高頻度で物理特定の状態をサンプリングするデバイスによって生成されたデータを処理するための簡潔な方法を提供します。このデータ型の一般的な用途は、ECGまたはEKGデバイスの出力データの表現です。

data エレメントは単一のスペース（Unicode文字 u20）で区切られた10進値の並びです。10 進数値に加えて、特別な値、「E」（エラー）、「L」（検出下限以下）、および「U」（検出上限以上）も使用することができます。複数の次元がある場合には、それぞれの次元はインターレース、つまり、ある特定の時点のすべてのデータ値は一塊で表現されます。factor のデフォルト値は1です。

SampledDataは、次の場所で使用されています。 Observation

1.13.0.11 Identifier

参考例 、 公式定義およびマッピングも参照してください 。

特定のシステムに含まれる単一のオブジェクトまたはエンティティに関連付けられている数字または英数字の文字列。通常、Identifier データ型は、リソースに含まれるコンテンツを、FHIR 以外のフレームワークやプロトコルで提供されている外部のコンテンツに結びつけるために使用されます。Identifier データ型は、特定のオブジェクトに関連付けられており、そのオブジェクトは、人為的にあるいはシステムにおける処理やエラーにより、変更又は廃止されることがありえます。

1.13.0.11.1 用語のバインディング

URI 形式を用いて指定されるsystem は、identifier データ型の表す ID を発行する主体（すなわち、ID の値の唯一性を保証する主体）です。これは、特定のアプリケーションかもしれませんし、ある集合や ID 群や、あるいは ID の重複のない発番方法についての一般に認知された標準や仕様かもしれません。value は、それを発行する system 内で一意であり、その出現場所のすべてで一貫した意味を持た＜なければなりません＞。system と value の値はいずれも、大文字と小文字が区別されます。

FHIR 仕様では、いくつかの有用な URI を掲載しています 。OID（urn:oid:）や UUID（urn:uuid:）については、HL7のOIDレジストリ に登録されている場合があり、特に、コンテンツを施設の境界を越えて共有・交換する場合には、事前に登録しておくべきです。identifier データ型の表す ID 自体が、元々グローバルに一意である場合（例えば、OID、UUID、または末尾のローカル部なしの URI）には、 system に "urn:ietf:rfc:3986" が、value に対応する URI を指定し＜なければならない＞。 。

状況によっては、system の値が未知で value の値だけ与えられる場合（例えば、バーコードをスキャンするだけの簡単な装置）や、または system が暗黙的に了解されている場合（大抵は、限定されたコンテキストでの単純な情報交換で、しばしばバーコードリーダーが使われる）があります。この場合、system の指すべき内容をコンテキストから安全に推測することができない限り、実業務にかかわる値のマッチングは実施すべきではありません。結果的に当初の想定より広いコンテキストでの情報共有が行われる可能性が非常に高いので、このような運用は、できる限り避けるべきで、system が不明な場合に value の値を実業務に使用できる範囲は本質的に限られます。

assigner は、この identifier データ型で表現される ID を割り当てた、レジストリ／州／施設等を指定するために用いられます。

識別子は以下の場所で使用されます： Condition、CarePlan、Supply、Device、Order、Organization、Procedure、Substance、DiagnosticReport、Group、ValueSet、ImmunizationRecommendation、DocumentManifest、MedicationDispense、MedicationPrescription、MedicationAdministration、Encounter、SecurityEvent、MedicationStatement、List、Questionnaire、Composition、DeviceObservationReport、Media、FamilyHistory、Other、Location、Observation、AllergyIntolerance、DocumentReference、Immunization、RelatedPerson、Specimen、OrderResponse、Alert、Patient、Practitioner、AdverseReaction、ImagingStudy および DiagnosticOrder

1.13.0.12 HumanName

参考例 、 公式定義およびマッピングも参照してください 。

テキスト表記、部分の構成および使用目的からなる人名情報。

人名は変更または否認されることがありえます。人は、異なるコンテキストで異なる名前を持つことができます。人名を構成部分に分割することは必ずしも重要であるとは限りませんが、人名を構成部分に分割することができて、それぞれの部分の重要性はコンテキストに応じて変化します。人名を構成するそれぞれの部分には、文化的に暗黙の意味を持っている場合も、持っていない場合もそれぞれあります。文化による人名の得的の構成部分に対する重要性の持たせようはさまざまで、システムがどれぐらい人名の構成部分に注意をはらわ＜なければならない＞かの程度は大きく異なります。

1.13.0.12.1 用語のバインディング

名前の構成部分には空白文字を含め＜てはいけません＞。ファミリーネームの場合、"Smith-Jones" のようなハイフン付きの名前は、単一の名前の構成部分とされますが、"Smith Jones" のようなスペースで区切られた名前は、複数の構成部分に分割されます。ファーストネームの場合は、それが記録されているすべてである時には、イニシャルをフルネームの代わりに使用することができます。

text エレメントには、表示されるべき形式での人名全体を指定します。この情報に付随して、人名の構成部分の指定がなくても、あってもかまいません。名前を更新するアプリケーションは、text に含まれる人名全体と与えられた構成部分との間に矛盾がないことを保証するか、人名全体か構成部分のどちらかしか存在しないことを保証し＜なければなりません＞。HumanName データ型のインスタンスに含まれた人名の構成部分のすべてにはアプリケーションが対応していない場合には、人名の構成部分のデータからいくつかを選択してスペースを使用して結合して使用することができます。

人名の構成部分の種類ごとに、複数指定された構成部分の順序は意味を持ち、遵守することが必要なことに注意してください。ファミリーネーム（姓）とファーストネーム（名）との間で、どちらが先に来るのが適切かは、文化や使用するコンテキストに依存します。

HumanName データ型は、以下の場所で使用されています：Organization 、 RelatedPerson 、 Patient および Practitioner

1.13.0.13 Address

参考例 、 公式定義およびマッピングも参照してください 。

郵便の宛先。世界中には、さまざまな形式で定義された郵便の宛先、住所があります。郵便の宛先、住所は、しばしば、患者または人に会うために訪問すべき場所を記録するために使用されます。

1.13.0.13.1 用語のバインディング

text エレメントには、実際に表示されるべき表記で、全体のアドレスを指定します。この情報に付随して、住所の構成部分の指定がなくても、あってもかまいません。住所の情報を更新するアプリケーションは、text に含まれる住所全体と与えられた構成部分との間に矛盾がないことを保証するか、住所全体か構成部分のどちらかしか存在しないことを保証し＜なければなりません＞。

制約事項

アドレスは、次の場所で使用されています。 Organization 、 Place 、 RelatedPerson 、 Patient および Practitioner

1.13.0.14 Contact

参考例 、 公式定義およびマッピングも参照してください 。

電話、電子メールなどを含むあらゆる通信技術についての、個人または組織の連絡先情報。

1.13.0.14.1 用語のバインディング

電話、ファックスやそれらに類似する連絡先を記録する場合には、その値は ITU-T E.123 に正しく従ったフォーマットであるべきです。しかし、これは、レガシーなデータや記録方法ではしばしば準拠することが不可能です。

制約事項

• Inv-2: value の値が指定されている場合、system の値が必要となります。(xpath: not(exists(f:value)) or exists(f:system))

Contact データ型は、次の場所で用いられます： Device、Organization、ValueSet、MessageHeader、Conformance、Profile、Location、RelatedPerson、ConceptMap、Patient および Practitioner

1.13.0.15 Schedule

参考例 、 公式定義およびマッピングも参照してください 。

複数回数発生することもある、将来のイベントを指定します。Schedule データ型で記録されるイベントは、それらが実際に発生した時でなく、そのイベントの発生が予想または要求されたときに記録に使用されます。Schedule データ型の表現は、複数の発生予定日時ごとのイベントのリストか、繰り返し条件が指定された単一のイベントか、実際のイベントを含まない発生条件飲みの指定のいずれかとなります。

1.13.0.15.1 用語のバインディング

event が指定されている場合には、それぞれについてevent.start{/0 } は指定し＜なければなりません＞。event.end に何も指定されていない場合、イベントが臨床的に意味のある範囲での、有限の、しかし未定の期間、持続すると想定されます。

スケジュールが繰り返し基準を含んでいる場合は、指定された期間またはある実世界のイベントに関連して、決められた回数繰り返すことになります。また、イベントが繰り返される場合には、イベントが発生可能な回数か、スケジュールを終了すべき日時の形で、スケジュールを終了すべき時を指定することができます。全く終了条件が指定されていない場合、スケジュールは他の場所で表現されているなんらかの基準で終了します。

制約事項

• Inv-1: event がないか、ひとつだけある場合は、repeat エレメントがひとつだけ存在できます。 (path: not(exists(f:repeat)) or count(f:event) < 2)
• Inv-2: Schedule.repeat について： frequency か when のいずれかのどちらかだけ、必ず存在し＜なければなりません＞。 (xpath on f:Schedule/f:repeat: exists(f:frequency) != exists(f:when))
• Inv-3: Schedule.repeat について：最大でも 1 つだけの count または end だけが存在できます。 (xpath on f:Schedule/f:repeat: not(exists(f:count) and exists(f:end)))
• Inv-4: Schedule.repeat.duration に関して： duration は正の値で＜なければなりません＞。 (path on f:Schedule/f:repeat/f:duration: @value > 0 or not(@value))

スケジュールは、以下の場所で使用されます：CarePlan 、 Order 、 MedicationDispense 、 MedicationPrescription および MedicationStatement

1.13.0.16 データ型未定エレメント

エレメントの中は、固定されたデータ型を持っていないものがあります。その場合、データ型は、ワイルドカード記号「*」で表されます。このような場合、エレメントのデータ型は、次のいずれかになります。

• integer
• decimal
• dateTime
• date
• instant
• string
• uri
• boolean
• code - エクステンションの定義が、適切なコードの集合にバインディングを提供する場合
• base64Binary
• Coding
• CodeableConcept
• Attachment
• Identifier
• Quantity
• Range
• Period
• Ratio
• HumanName
• Address
• Contact
• Schedule
• Resource - 別のリソースへのリファレンス

エレメント名の末尾に "[x]" がつき、これは大文字小文字の区別のついたデータ型名に置換されます。

データ型未定のリファレンスは、次の場所で使用されています。 Questionnaire と Profile

1.13.0.17 その他のデータ型

以下のデータ型は、データ型に含まれるものとして定義されていますが、FHIR 仕様書の他の箇所に記載されています：

• Resource -すべてのリソースの概念的な基本クラス
• ResourceReference - あるリソースから別のリソースへのリファレンス
• Extension - リソースに、追加のデータを格納するために使用
• Narrative - リソースのコンテンツを人間が読める表現で伝達する