==========
- _sort
將查詢所得進行特定欄位之排序，此特定欄位，當然是只有支援之查詢參數。預設是遞增，要遞減就在欄位前面加減號。這邊排序的結果，並不會影響到Server上的排序。
- 確認是正確的URI。
- 可惜，Server沒有支援。
- _count
標準文件與Server支援度有差異，不知能否實作。(我猜啦)
應該這麼解釋，Bundle回來的資料非常多，所以，應該要支援Page的機制。若依據範例應該長這樣子：
<Bundle xmlns="http://hl7.org/fhir">
<!-- snip metadata -->
<!-- This Search url starts with base search, and adds the effective
parameters, and additional parameters for search state. All searches
SHALL return this value.
In this case, the search continuation method is that the server
maintains a state, with page references into the stateful list.
-->
<link>
<relation value="self">
<url value="http://example.org/Patient?name=peter&stateid=23&page=3"/>
</link>
<!-- 4 links for navigation in the search. All of these are optional, but recommended -->
<link>
<relation value="first"/>
<url value="http://example.org/Patient?name=peter&stateid=23&page=1"/>
</link>
<link>
<relation value="previous"/>
<url value="http://example.org/Patient?name=peter&stateid=23&page=2"/>
</link>
<link>
<relation value="next"/>
<url value="http://example.org/Patient?name=peter&stateid=23&page=4"/>
</link>
<link>
<relation value="last"/>
<url value="http://example.org/Patient?name=peter&stateid=23&page=26"/>
</link>
<!-- then the search results... -->
</Bundle>
也就是說，在<link>下應該要提供URI，讓Client程式能夠實作上一頁，下一頁的機制。
回頭看看，之前查詢的結果。這台伺服器所提供的URI卻是
"link": [
{
"relation": "self",
"url": "/Patient"
},
{
"relation": "last",
"url": "/Patient?_skip=230"
},
{
"relation": "next",
"url": "/Patient?_skip=10"
}
],
而我查FHIR文件，是沒有這個_skip的參數說明，但這是RESTful API所支援。也就是說，這個Server提供三個跳頁連接，last是直接到最後一筆，next是跳到第10筆。
上機實作吧。
 |
| 沒加 |
 |
| 有加 |
看出差異了嗎？
預設值是每一頁10筆資料。當加上了_count=20，表示每一頁要有20筆資料。所以，Next就會是_skip=20，因為第一頁有20筆，第二頁當然要先跳掉20筆。
- _include與_revinclude
 |
| 沒有_include |
我們先看這個沒有加_include的查詢
- 確認URI，沒有加任何查詢參數。
- 總共有40筆。
- 這一頁帶10筆回來。
再看看有帶_include的話。
 |
| 有_include |
- 確認URI有_include查詢參數
- 總共有40筆。
- 這次帶回11筆？喔！原來，這10筆MedicationRequest(主體Resoource)，有參照的patient查詢參數者，也會帶回來。(原本這10筆的subject，符合參照規範者，只有ID為part1的這一筆。)
那_revinclude又是怎麼一回事呢？(好不容易找到適合案例)
- 確認URI有_revinclude查詢參數
- 總共有234筆，每次傳10筆，終於來到第四頁(也就是省略30筆)。終於找到案例了。
- 除了帶回Patient資料外。還要帶回Encounter，但，這個Encounter的patient查詢參數，是參照於本頁中的某一筆Patient。
能夠理解這兩者差異嗎？
_include是本體內容有參照element，被參照的Resource放進來。
_revinclude是本體內容有被指定之Resourc參照到的話，則把參照到這個本體的外部Resource放進來。
- _summary
只想看重要欄位。
 |
取完整 _summary=false
|
 |
取摘要_summary=true
|
- _total
這個Server不會實作。因為，在Bundle Resource有Total這個element。
- _element
這是用來指定要回傳哪些element。必要欄位不用寫入，他一定會回傳。
- 確認URI所加入的查詢參數與值。
- 回傳我們所要求的element。
- _contained
要搞懂這個，得先對Resource有很熟悉。大部分的Resource都繼承於DomainResource。而他有一個element叫contained。這個做什麼用的呢？跟參照有關。參照的形式有很多種，我們大部分看到的都是Resource/ID。有需要時，再點選連結取得資料，當然前面加上URL就是向外部要資料。但是，還有一種情境是乾脆把這些外部參照的資料，就放在本體中。所置放的位置就在contained裡面，每一個放在裡面的Resource會有自己的ID，此時參照的寫法就變成"#ID"了。
所以，_countained設成false就是不要把這些參照resource放進來。true就是要。至於還有個both就不好理解，那就實作看看了。
先看正常的查詢，也就是會帶Resource到contained位置。
- 確認URI的查詢內容
- 這個還是解釋一下。MedicationRequest有medication的查詢參數。其實他是指向Medication。所以，我們去看Medication有一個查詢參數ingredient-code，他是token，所以可以用code去查詢了。
- 因為上述查詢是並在一起，Medicaiton就會被放到Contained裡面。
- 此時，會有一個ID，提供給參照欄位之參照點。
不過，我還是沒有實作成功。還是回傳無支援。
再想想吧。
=========
===後記===
=========
記得，實務操作不會如此。反而是系統分析師要去定義設計適當流程與畫面，產生適當的查詢字串然後跟後台要資料，再處理之，
Meta
versionId
security
DomainResource
extension