3.1.1 will fix a couple search parameter definitions which had diverged from the base specification: FHIR#27887 and FHIR#27892

I think those were the only two causing us trouble, but after doing some more analysis, I found a few more search parameters where the expression listed in US Core differs from the expressions from which they derive.

On the condition resource, the base spec defines `onset-date` to apply to Condition.onset when it is either a dateTime OR a dateRange.

Condition.onset.as(dateTime) | Condition.onset.as(Period) vs
Condition.onset.as(dateTime)

US Core differs in that, as currently defined, there would be no conformance expectation for a search on this parameter to return a Condition resource which had an onset of type Period (some range of datetimes).

{{}}

On the Organization and Location resources, the based spec defines a `name` parameter which applies both to the name field of these resources, but also their "aliases".

Organization.name | Organization.alias vs
Organization.name

Location.name | Location.alias vs
Location.name

For example, for Organization organization like the following:

"name": "Health Level Seven International",
"alias": [
"HL7 International"
]

the core FHIR specification parameter says that a search for name=HL7 should return a resource whereas the US Core parameter (as currently defined) would not.

In my opinion, the US Core SearchParameter definitions should be brought in line with the expressions used in the core specification. The only thing that should be different are the conformance expectations around multipleAnd, multipleOr, modifiers, chains, and the like.

See the following chat for some discussion related to this:

https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Why.20do.20IGs.20redefine.20search.20parameters.20from.20the.20base.20spec.3F/near/205612879