1.6 拡張性（§1.6）

この情報交換標準は、医療保健分野における、いくつもの行政区分、適用領域そしてさまざまな機能実現方法を包含する、一般的に合意された共通の要求事項に基づいています。そのため、個別の実装システムにおいては、この仕様には直接含まれないけれども、ごく妥当な要求事項が生じることは普通のことです。そのような要求事項をすべて取り込むことは、この仕様を煩雑で実装が困難なものにしてしまいます。その代わりに、この仕様では、そのような顕著な追加の要求事項は追加拡張として実装することを想定しています。

したがって、この仕様において拡張性は重要な部分を占めています。リソースのすべてのエレメントは extension エレメントを子要素として持つことができ、リソースの元の定義には含まれない追加の情報を表すことができます。コンフォーマントなアプリケーションは、追加拡張が含まれているからといって、リソースを拒絶することはできません。ただし、追加拡張の特定のコンテンツを理由にリソースを拒絶せざるを得ないことはあり得ます。

他の仕様と違って、この仕様では、どんなアプリケーションやプロジェクトや標準規格でも、使用したり定義を行う施設や機関の如何に関わらず、追加拡張を使うことに何の咎めもありません。追加拡張を活用することで FHIR の仕様は、すべての人にとって共通する部分での単純性を実現できるのです。

追加拡張の仕様を安全で管理可能なものとするために、追加拡張の定義と使用には厳格な統制が適用されます。どの実装者にも追加拡張を定義することが許されていますが、追加拡張の定義の一部として適合しなければならない一連の要求事項があります。

Extension エレメント（§1.6.1）

リソースのすべてのエレメントには、エレメント中に何度も出現してよい、省略可能な Extension エレメントが含まれます。Extension エレメントは、その他のすべての下位エレメントに先立ち、最初の下位エレメントとして出現します。以下は、各リソースに出現する Extension エレメントのコンテンツモデルです：

留意点：

• url は必須フィールドで、Extension エレメントのコンテンツと意味を定義するリソースプロファイル中の定義を指定します。
• isModifier は Extension エレメントの値が他のエレメントの解釈、意味や理解に影響するかを示します。その用法については後述の議論を参照してください。
• Extension エレメントの実際のコンテンツは value[x] エレメントの単一の値か、それぞれ独自の定義への url とコンテンツを持つ別個の Extension エレメントの入れ子になったリストから成ります。
• Extension エレメントは、単一の値（つまり value[x] エレメント）か、下位の Extension エレメントのいずれかを持たなければなりません。value エレメントは、実際のコンテンツか、Narrative からのリファレンスのターゲットである id アトリビュートの両方またはどちらかを持たなければなりません。
• Extension エレメントが内部リファレンスのターゲットである時には、リファレンスは Extension エレメントの値に対して行われます。リファレンスのターゲットに、Extension エレメントを付加するのが許されるのは、その Extension エレメントが value[x] を持たないときだけです。

value[x] エレメントの x には、既定のデータタイプ名のいずれかが、定義と同じ大文字小文字の並びで入ります。そのコンテンツには、その x に入るデータタイプで定義されたものか、さらに Extension が適用されたものが入ります。x に入るデータタイプは以下の通りです：

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

入れ子の Extension は、元の Extension が複雑なコンテンツを定義する場合（例えば、単純なデータタイプでなく、複数の部分からなる Extension を定義する場合）に用いられます。Extension 自身の値を拡張しなければならないときは、その値が value[x] エレメントのコンテンツに入ります。

isModifier（§1.6.2）

Extension は、追加の情報を提供するだけでなく、既存のエレメントの意味を修飾したり、ときには意味を反転させることさえあります。例えば、実装によっては AllergyIntolerance に、アレルギーの情報には「疑いのみ」のものも含まれることを示すために「確度」についての Extension を追加することがあるかもしれません。もし Extension の値が「かなり低い」である場合には、アレルギー／不耐性情報全体の意味は変化しますし、実装システムは Extension を無視すべきではありません。このような他のエレメントの意味を修飾する Extension を無視するのは安全ではないので、インスタンス中に明示しなければなりません。

アプリケーションがリソースのコンテンツを処理する際に、「他のエレメントを修飾する」（"isModifier"）と設定されている Extension を認識できないで、影響をうけるエレメントからのデータを処理する場合には、そのアプリケーションは、データの処理を拒否するか、そのデータの処理の結果生じるすべての出力やアクションにデータの信頼性に関する警告を付加するかの、いずれかの処理をしなければなりません。

サーバーやバックグラウンドプロセスといった、リソースを右から左に動かすだけで「リソースのデータを処理しない」アプリケーションは、未知の Extension がないかのチェックはする必要がありません。リソースからデータをコピーして別のコンテキストで利用する（人間に見せる、意思決定支援、拡張をサポートしない別フォーマットへの変換など）アプリケーションはすべてデータを処理していることになります。

Narrative は常に、人間にそれだけ見せても安全なようにしなければならないことに注意してください。「他のエレメントを修飾する」（"isModifier"）と設定されている Extension は Narrative に反映されなければなりません。アプリケーションは、認識できない Extension に "isModifier" エレメントが存在しない、あるいは false に設定されている場合は、その Extension を無視しなければなりません。

Extension を定義する（§1.6.3）

Extension は、プロジェクト単位や各種行政組織から HL7 自身を含む国際標準化組織に至るまで、その主体の規模や種類によらず定義することができ、リソース・プロファイルの中に記述されて公開されます。Extension は常にある特定のコンテクスト、つまり拡張対象のエレメントの性質に応じて定義されます。以下は Extension のコンテクストの例です：

さらに、Extension の定義では、拡張対象の特定のエレメントの値に制限を課して、Extension を適用してよい場合を限定できます。Extension は、定義された条件に合う拡張対象にだけ適用しなければなりません。

各 Extension は以下のフィールドを用いて定義されます：

留意点：

• マッピングは機械処理可能（演算可能なロジック）でなくても構いません。他の仕様へのマッピングを指定することもできます。

Extension が含まれるリソースを交換する時には、そのリソースを共有するすべての当事者に対して、Extension の定義がアクセス可能でなければなりません。各 Extension は、リソース・プロファイルという形で存在するその Extension の定義のソースへのリファレンスとしての URI を保持しています。ソースの指定は http: URL のような、その定義のコンテンツに責任を持つ最終的なアクセス先を直接指定した形式にすべきです。そのようなリファレンス先としては、リソースプロファイルをサポートする FHIR RESTfulサーバや、正式に公開されている国内標準等への（例えば urn: を使用した）論理リファレンスを指定することが推奨されます。

Extension の統制（§1.6.4）

HL7 は FHIR のリソースの基本エレメント構造を定義するだけでなく、Extension による拡張機能も定義し公開します。リソースの基本構造を単純で簡潔なものに保ち、実装者が世界全体を対象するだけの全ての機能に真正面から対応しなくてもよいように、HL7 は FHIR の新しいデータの定義を、基本エレメント構造に組み込むよりは、 Extension として公開します。HL7 によって定義される Extension は must-understand になることは決してないことに注意してください。なぜならば、HL7 が誰もが理解しなければならない Extension を定義するならば、拡張ではなく、どのみち誰もが理解しなければならないリソースの正式なコンテンツに組み込むべきだからです。

インスタンスで Extension を使用する前には、その Extension は公開されなければなりません。HL7 は 2 種類の Extension の登録リストを管理し、ユーザは自分の定義した Extension をそこに登録することが推奨されていますが、これは必須ではありません。最低限必要なのは、Extension の定義はその使用者がアクセスできるコンテクストで公開されなければならないということです。たとえば、単一の組織の中で交換される Extension については、その組織のイントラネットにその Extension の定義が置かれるといった具合です。しかしながら Extension の自然な傾向として、リソースは組織の範囲を超えて流通しがちですから、HL7 の登録リストに常に登録するのが得策です。

HL7 は 2 種類の Extension 登録リストを提供します。ひとつめは HL7 に正式承認された Extension のリストです。もうひとつは、HL7 コミュニティへのサービスとして、誰もが Extension を登録できます。

HL7 の手による Extension の定義を含むプロファイルは、リソース・コンテンツ本体とともに FHIR 仕様の一部として、バロット対象となったり、FHIR とは別の仕様の一部として公開されたりするかもしれません。HL7 が Extension を FHIR の仕様の一部として公開している時には、対象となるデータがインスタンスにに表現される際には必ず、その Extension を使わなければなりません。アプリケーションは相互運用性を最大限に高めるため、FHIR 仕様の一部ではなくとも HL7 が定義している Extension を、対象に当たるデータを表現する時には使用すべきです。Extension を定義しているプロファイルをリファレンスするときには、そのプロファイルにコンフォーマンスを宣言している実装システムは、対応するデータエレメントを表現する時には、そのブロファイルで定義されたり、インポートされている Extension を使わなければなりません。

実装者にとっての煩雑さを最小にするために、HL7 は HL7 で承認された Extension で定義されているコンテンツは、リソースの将来のバージョンにおいても、リソースのコア・リソースに定義されるコンテンツに格上げすることはありません。

実装者は、自分の作った Extension をHL7 と共有し、HL7 の Extension 登録リストに登録することが推奨されています。各ドメインの委員会は、登録された Extension の中から HL7 承認済みの Extension に格上げするものを選んだり、実装者のコミュニティの充分広い範囲で共有されているものに限っては、基本のリソース構造に組み込む作業を行います。

相互運用性を損なう問題を防ぐために、一旦公開された Extension の定義を変更してはなりません。（相互運用性に影響しない、説明文の少しの変更は認められています。）既存の Extension を変更する代わりに、新しい Extension を公開すべきです。Extension の改版では、Extension の適応可能なコンテクストを拡大することは認められていますが、以前に挙げられていた適応可能なコンテクストを削除したり、制約を加えることは認められていません。

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

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

© HL7.org 2011 - 2012 License