HL7 FHIR JP Core ImplementationGuide - Local Development build (v1.1.0). See the Directory of published versions

Must SupportとCardinality(多重度)のルール

CardinalityとMustSupport組み合わせ

MustSupportが付与されていない要素について

この節では各CardinalityとMustSupportの状態ごとのサーバおよびクライアント動作について表形式にて記載している。JP Coreでは、日本国内で患者データにアクセスするための最小限の適合性要件を定めるという理念に基づき、いずれの要素にもMustSupportを付与しなかった。

なお、データが存在しない場合の取り扱いについては、欠損値（データが存在しない場合）の扱いにて詳細を記載した。

最小Cardinalityが1であることは、必ずしも有効なデータを持つことを意味しない。最小Cardinalityが1であることは、要素が存在することのみを要求しており、例えば、その要素はDataAbsentReason拡張のみを持つかもしれない。

プロファイルによっては、各要素のCardinalityに加えてConstraintsによってさらなる制約が規定されていることがあるので注意すること。

MustSupportフラグが無い場合はFHIRの規約通りであり、以下にその概略を記す。

MustSupport有無	Cardinality	Queryケース (Server)	Queryケース (Client)	Create / Update ケース (Client)	Create / Update ケース (Server)
無	0..1, 0..*	このエレメントを送信してもよい。	このエレメントを受信することを前提にできない。 また、is-modifierフラグがない限り受信したエレメントを無視してもよい。*2	このエレメントを送信してもよい。	このエレメントを受信することを前提にできない。 また、is-modifierフラグがない限り受信したエレメントを無視してもよい。*2,*3
無	1..1, 1..*	Cardinalityの制約に従い、エレメントを送信しなければならない。*1	このエレメントを受信することを前提としてよい。*1 また、is-modifierフラグがない限り受信したエレメントを無視してもよい。*2	Cardinalityの制約に従い、エレメントを送信しなければならない。*1	このエレメントを受信することを前提としてよい。*1 また、is-modifierフラグがない限り受信したエレメントを無視してもよい。*2,*3

*1 Nullや空文字列を値として送信することはFHIRの規約上許可されていない。また、最低Cardinalityが1以上であっても必ずしも有効な値を持つことは意味せず、constraintsなど追加の制約が無い限り、DataAbsentReason拡張といった何らかの拡張を持つ場合などもcardinalityの制約を満たすことに注意する。例えば、「”unsupported”というDataAbsentReasonを持つ要素」もこの要件を満たしうる。データが欠損している場合の取り扱いの詳細については欠損値（データが存在しない場合）の扱いを参照のこと。

*2 is-modifierフラグのついたエレメント全てにMustSupportフラグが付与することができれば、MustSupportフラグのついていない全てのエレメントを安全に無視できるようになる。

*3 Transaction Integrityに、サーバがCreateの要求からエレメントを変更・削除する場合の例が挙げられており、その中に「サーバがサポートしていない場合」が含まれる。MustSupportのエレメントを変更・削除する場合は、それ以外の理由に限られるべきと考えられる。

推奨するMustSupportの定義

なお、本プロファイルから派生するプロファイルにおいては、下記のMustSupport定義を推奨する (MAY) 。また、「あるエレメントがMustSupportとマークされている場合、そのエレメントの全ての下位エレメントもMustSupportとみなす」よう定義することを推奨する (MAY)。

MustSupport有無	Cardinality	Queryケース (Server)	Queryケース (Client)	Create / Update ケース (Client)	Create / Update ケース (Server)
有	0..1, 0..*	システムが特定のデータエレメントに関する情報を有する場合、このエレメントを用いて送信しなければならない。 情報を送信できず、データ欠落の正確な理由が存在する場合は、欠落した情報の理由を、値セットから(nullFlavorsなどの)値を使用して、またはdataAbsentReason拡張を使って送信しなければならない (SHOULD)。 情報を送信できず、データ欠落の理由が明らかでない場合*4は、このエレメントを含めてはならない。	エレメントが存在しないことを、送信システム内にデータが存在しないことと解釈するものとする。	システムが特定のデータエレメントに関する情報を有する場合、このエレメントを用いて送信しなければならない。 情報を送信できず、データ欠落の正確な理由が存在する場合は、欠落した情報の理由を、値セットから(nullFlavorsなどの)値を使用して、またはdataAbsentReason拡張を使って送信しなければならない (SHOULD)。 情報を送信できず、データ欠落の理由が明らかでない場合*4は、このエレメントを含めてはならない。	エレメントが存在しないことを、送信システム内にデータが存在しないことと解釈するものとする。 サーバは、後で要求された時に送信されたエレメントと同じエレメントを用いて応答するべき (SHOULD) であり、理由なく変更してはならない。*3
有	1..1, 1..*	システムが特定のデータエレメントに関する情報を有する場合、このエレメントを用いて送信しなければならない。 情報を送信できず、データ欠落の正確な理由が存在する場合は、欠落した情報の理由を、ValueSetから(nullFlavorsなどの)値を使用して、またはdataAbsentReason拡張を使って送信しなければならない (SHOULD) 。なお、この項目は、固定値や、欠損するとリソース自体の意味が不明確になる場合など、原則として値が存在すると期待されるエレメントに設定される。	このエレメントを受信することを前提としてよい。	システムが特定のデータエレメントに関する情報を有する場合、このエレメントを用いて送信しなければならない。 情報を送信できず、データ欠落の正確な理由が存在する場合は、欠落した情報の理由を、ValueSetから(nullFlavorsなどの)値を使用して、またはdataAbsentReason拡張を使って送信しなければならない (SHOULD)。 なお、この項目は、固定値や、欠損するとリソース自体の意味が不明確になる場合など、原則として値が存在すると期待されるエレメントに設定される。	このエレメントを受信することを前提としてよい。 サーバは、後で要求された時に送信されたエレメントと同じエレメントを用いて応答するべき (SHOULD) であり、理由なく変更してはならない。*3

*4 DataAbsentReason拡張を参照すると、unknownの定義は「The value is expected but is not known.」であり、例えば定義上「値が存在するかどうかも分からない」状態に対応するCodeは割り当てられておらず、そのような場合に「データ欠落の理由が明らかでない」状況が生じ得る。また、当然ながらMustSupportの要素におけるDataAbsentReasonとして”unsupported”は使用すべきでないと考えられる。