Existing Wording: in addition to the get based search method above, servers that support search SHALL also support a POST based search:

Proposed Wording: in addition to the get based search method above, servers that support search SHOULD also support a POST based search:

Comment:

As the owner/oparator of Provincial EHR assets, the development, testing, and rollout of both GET and POST service functionality in a high-complexity integrated environment is very resource-intensive. When working with known integration partners and client users, it is easy to negotiate support for just GET or POST, and not necessarily both. Anecdotally, we have three FHIR-capable Provincial EHR Assets in production that only require HTTP GET for search (with more on the way). There have been no client requests for support of HTTP POST for Search, and thus no meaningful justification for the cost to implement a POST service for each of those assets, aside from being deemed "FHIR-Conformant".

Summary:

Reduce FHIR Search Conformance requirement from "SHALL support both get & post" to "SHOULD support both get & post"