0
StructureDefinitionからコードを生成する場合、baseで参照されるリソースのクラスをスーパークラスとして使用するのは明らかです。他のリソースを拡張するリソースを扱う方法
（max="0"がmax="*"によってオーバーライドされる場合StringからList<String>に例えば）baseリソースのプロパティの種類を変更することができる別のリソースに基づいてリソース。
これは、サブクラスがスーパークラスのインターフェイスに準拠しなければならないため（強く型付けされた言語では機能しませんが、一般化できません）。
これに対処する正しい戦略は何でしょうか？
differentialの代わりにsnapshotを使用し、baseリソースのクラスを拡張することはできません。
私はまだElement、BackboneElement、Resource、DomainResourceような、より一般的なスーパークラスのいずれかを拡張する必要がありますか？
私の推論に欠陥がありますか？
を変更します。だからこれはスーパークラスとして 'base'を使い、' differential'からサブクラスを生成すること（そして拡張を適用すること）が安全であることを意味しますか？ –
プロファイリングについて話すとき、サブクラスの全体の考え方はややこしいです。繰り返しアイテムを5つの異なる制約セットにスライスすると、どのようにサブクラスでそのアイテムを表示できるようにしたいですか？それは5要素ですか？まだ1つの反復要素ですか？同じコレクションの2つの異なるビューですか？私たちはまだ、プロファイルをクラスとして表現する最善の方法について私たちの頭を完全にはめ込んでいません。 –
ありがとう、それは役立ちます。私はまだスライスが正確に何の周りに私の頭を包むために持っています。より多くの例を示すドキュメントはありますか？私が見つけたほとんどのものは非常に抽象的なものであり、あまり詳しく説明しません。ドキュメントは事実を確認するのに最適ですが、まだ慣れていない概念を頭で囲むときにはかなり難しいです。また、FHIRコミュニティがオンラインで議論している場所もありますか？すべての種類の質問がそれに適しているわけではありません。 –