在Base Type的Element這邊系列中，長了兩個很奇怪的類別BackboneElement繼承了Element，而BackboneType繼承了DataType，兩個類別的欄位內容卻一模一樣。這到底是怎麼一回事呢？
這個設計很明顯就是為了實踐FHIR所強調的20-80理論，但也苦了實做者。
先來看這張圖：
=====BackboneType=====
原來BackboneType其實就是為了幾個Complex Type擁有modifierExtension的機制。有哪幾個呢？依據文件，目前(是的，只能說目前，未來還是有可能增加)Timing、Dosage與ElementDefinition這三個DataType。注意了，我拿Address與Timing來比對。
文件中，兩者都是繼承了Element。所有的Complex Type都是寫繼承Element，沒有DataType。僅能從描述中得知Timing繼承了一個modifierExtension的屬性。這個程式碼單純，就是ComplexType的一種。就不多做解釋了。
=====BackboneElement=====
一定很好奇，除了Base Types的圖中有看到BackboneElement之外，他到底在哪裡呢？原來，他在Resource那邊。找個大家熟悉的Patient Resource吧。
原來他也是一種DataType，但是，他僅是抽象類別，實際的內容還是要看此Elmenet之下的宣告。有感應到了嗎？原則上所有的資料型態都會有extension，但是這類BackboneElement的類別，還會多了modifierExtension。(與BackboneType給的邏輯不太相同)。
BackboneElement的設計架構非常複雜。首先，他會有一個抽象類別，就跟BackboneType一樣，要有modifierExtension屬性。
而分散在Resource裡的BackboneElement，其結構每一個都不一樣。所以，得為每一個不同的BackboneElement設計共用父類別，而這個父類別必須走Reflect架構，這樣子才能夠因應不同的BackboneElement。這個類別的程式非常複雜，也不好解釋。有緣再說了。
來看一下Resource類別是怎麼設計的。仍以Patient Resource為例。
Resource本身當然是繼承了ResourceType系列，這部份後續才會說明。
而Patient Resource裡面的BackboneElement必須帶入類別，這樣子才會知道有哪些欄位屬性，這才方便進行後續處理。
補充說明一下：這個Resource類別的產生，是另一個專案用T4技術自動化產生。這塊技術也是有緣再說明吧。(哈～畢竟一路走來，都是自言自語比較多)
