此操作與一般查詢病人的主要差別在於：

• 除非用戶端另有請求，否則伺服器會在單個Bundle中回傳整個結果集（而不是使用分頁）
• 伺服器負責確認回傳哪些Resources（而不是用戶端指定）

這使用戶端無需確定其可以或應該要求什麼，特別是關於包含的Resources。伺服器應考慮在回傳的Resources上回傳適當的Provenance和AuditTrail，即使這些Resources不是病人 compartment的直接部分。

假設伺服器已適當地識別並保護了上下文，並且可以將授權上下文與單個病人相關聯，或者確定上下文是否具有對指定病人的許可權（如果有），或者可以確定適當的病人清單以從請求的上下文中為其提供資料。如果沒有指定的病人（GET/Patient/$everything），並且上下文未與單個病人紀錄關聯，則實際的病人清單是與請求關聯的使用者有權存取的所有病人。這可能是病人有權存取的家庭中的所有病人，也可能是健康照護提供人員有權存取的病人，或者可能是整個系統上的所有病人。在這種情況下，伺服器可能會選擇回傳錯誤而不是所有紀錄。

當此操作用於一次存取多位病人紀錄時，回傳的Bundle可能含相當多的資料；伺服器可以選擇要求非同步發出此類請求，並與大量資料格式相關聯。或者，用戶端可以選擇逐頁瀏覽結果集（或者伺服器可能需要這樣做）。對結果進行分頁的操作與使用_count參數和Bundle連結進行查詢時相同。實作者應該注意，分頁將比簡單地一次回傳所有結果（更多網路流量，多次延遲）慢，但可能需要這樣做，以免耗盡可用記憶體讀取或寫入單個Bundle中的整個回應。與查詢不同，$everything操作沒有固有的顯示順序。伺服器可以考慮按上次紀錄更新對回傳的Resource進行降冪排序，但不是必需的。

提供_since參數是為了支援定期查詢，以存取自上次查詢以來有關病人的其他更改資訊。這意味著_since參數基於紀錄時間。_since參數的值應設置為來自伺服器的時間。如果使用直接回應，則這是回應表頭中的時間戳記。如果使用非同步介面，則這是JSON回應中的交易時間戳記。伺服器應確保託管的時間戳記，以便用戶端不會錯過任何更改。在交易落在時間邊界上的情況下，客戶端應該能夠多次處理存取相同的回應。用戶端應確保其他查詢參數是常數(constant)，以確保在執行定期查詢時有一組一致的紀錄。