Type: Technical Correction
Status: Applied (View Workflow)
Specification:US Core (FHIR)
Raised in Version:3.1.0
Work Group:Cross-Group Projects
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
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
Location.name | Location.alias vs
For example, for Organization organization like the following:
"name": "Health Level Seven 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: