Stream: fhir/infrastructure-wg
Topic: GF#20470
Lloyd McKenzie (Oct 03 2019 at 13:02):
The application of this task stripped multipleAnd, multipleOr and modifiers from the computable search parameter representations. However it didn't strip comparators. I think it should have.
Grahame's response: Need to discuss GF#20470 with committee. I didn't really agree with the fundamental idea behind the task - we can profile things out elsewhere, why is this different. And people are going to complain since the modifiers will not be machine defined anywhere. Comparators just dds to my discomfort. And I won't do it unless the committee is explicit about it
So seeking to put this on the agenda for Monday's call
Eric Haas (Oct 03 2019 at 13:54):
Either way ( list none or list all) need to specify what you support. When writing conformance specification for an IG attatching conformance expectations works, for an implementation how would you profile it? Derive from the base and only list modifiers and comparators you support?
Lloyd McKenzie (Oct 03 2019 at 14:23):
Yes
Eric Haas (Oct 03 2019 at 14:26):
specifically for example:
id us-core-foo
url : http://hl7.org/fhir/us/core/SearchParameter/us-core-foo
version : 4.1.0
name : USCoreConditionFoo
derivedFrom : http://hl7.org/fhir/SearchParameter/clinical-foo
...
mulitpleOr : True
mulitpleAnd : True
modifier : missing
modifier : text
modifier : not
modifier : in
Eric Haas (Oct 03 2019 at 14:29):
maybe we should add some guidance here? http://hl7.org/fhir/profiling.html#search
Lloyd McKenzie (Oct 03 2019 at 14:30):
That's the long-term solution, yes. The issue was that we changed how we were declaring search parameters without declaring how profiling happened.
Last updated: Apr 12 2022 at 19:14 UTC
