Stream: fhir/infrastructure-wg
Topic: SPs
Eric Haas (Apr 19 2019 at 23:52):
To FHIR-I folks I have alway pushed to just create SPs for all elements, I don't see the harm in just stating and listing a FHIR SP for every @#$ element in the spec? They can be autogenerated far as I can tell. Then the composites or special ones can be hashed out by the work groups and can black llist the ones they don't want ( although I don't see why you would do that - just don't implement them) this would eliminate WG overhead and maintenance in managing SP requests.
Eric Haas (Apr 19 2019 at 23:53):
That + getting rid of RIM mappings and Xpath2 and I'll be happy ;-)
Lloyd McKenzie (Apr 19 2019 at 23:56):
Search parameters should, in principle, reflect the 80%. The ones we define provide an indication to server implementers what they should seriously consider supporting and give an indication to clients what types of SPs are most likely to exist in the servers they encounter. Algorithmically generating them for everything wouldn't help the implementation community. And it's their lives we're trying to make easier, not ours. In addition, when designing search parameters, there's often cognative effort required to figure out when SPs should be compositional, what type to use, whether anything special needs to be done in the path expression, whether one parameter should search multiple paths, etc.
Lloyd McKenzie (Apr 19 2019 at 23:56):
XPath2 will go away soon. And you can sell me on removing RIM much more easily than auto-generating search parameters.
Eric Haas (Apr 21 2019 at 04:22):
I seriously doubt there is much consideration in making up sps. i make a wild ass guess based on what seems reasonable or just list all the elements or all the pattern and then wait for trackers to come trickling in. It really seems easier the other way let the server decide the 80% for themselves.
Eric Haas (Apr 21 2019 at 04:24):
trackers trickling on SPs is becoming annoying and considering takes up to 18 months and a new version not very efficient.
Lloyd McKenzie (Apr 21 2019 at 06:28):
It's not really any different than new data elements. I agree that search parameters don't get enough attention (both in terms of which shouldn't be there as well as which should), but that isn't a reason to make the situation worse. Again, our focus needs to be on what will make the spec most useful to implementers, not what's less fuss for us. (And defining new SPs isn't really any more work than defining new extensions - and we do as many or more of those.)
Josh Mandel (Apr 24 2019 at 21:11):
I'm sympathetic to both sides here. If generating even some/most search params was a rote operation (i.e., names and types could be automatically determined from the path), we'd avoid the situation where the lack of a search param led to different servers creating their own with slight differences.
Lloyd McKenzie (Apr 24 2019 at 21:15):
I think that's less of a problem than implementers having no guidance about what's reasonable to support.
Lloyd McKenzie (Apr 24 2019 at 21:15):
And the latter can always be rectified in the next version.
Brian Postlethwaite (Apr 24 2019 at 21:25):
And search parameters are easy to pre-adopt.
Josh Mandel (Apr 24 2019 at 22:57):
The truth is though that the complete set of search parameters we define today is big, and different ones are important in different contexts. Mostly I've seen servers treat them entirely generically (like HAPI) or very selectively (like, say, servers following guidance in the US Core IG).
Josh Mandel (Apr 24 2019 at 22:57):
It's not clear that our selectivity is providing value for either group. But I'm open to arguments otherwise...
Grahame Grieve (Apr 25 2019 at 00:15):
more search parameters = more strorage + more commit time
Michael Donnelly (Apr 26 2019 at 18:10):
How many cases have you folks heard of where a client wanted to use a search parameter that one or more EHRs don't support? I worry that the more search parameters we have the higher the odds of clients needing ones that aren't there.
I think Lloyd's point about focus is a good one.
Josh Mandel (Apr 26 2019 at 20:43):
(I'm all for focus; I'm just not sure it's helpful in the core spec here. I wish defining most search parameters didn't require deciding on things like what to call them.)
Lloyd McKenzie (Apr 26 2019 at 21:01):
Well, technically servers are free to call them different things, but doing that would confuse people. We need to come up with names for data elements too - not sure why coming up with ids and recommended codes for search parameters would be any different.
Josh Mandel (Apr 26 2019 at 22:04):
Just because we already must come up with standardized names for the elements; that's the core structure of our resource definitions.
Josh Mandel (Apr 26 2019 at 22:04):
And then we come with names for some search parameters.
Josh Mandel (Apr 26 2019 at 22:04):
I don't feel super strongly about this, but I get @Eric Haas's frustration.
Lloyd McKenzie (Apr 29 2019 at 13:02):
We come up with names for some elements too - the 80% rule guides that and is supposed to guide our definition of search parameters too. Others are free to define additional search parameters just as they're free to define extensions.
Josh Mandel (May 01 2019 at 01:43):
Is http://wiki.hl7.org/index.php?title=FHIR_Guide_to_Designing_Resources#What_search_parameters_should_be_included_in_a_resource.3F the places where this methodology is (supposed to be) documented, or is this page orphaned?
Josh Mandel (May 01 2019 at 01:44):
(We don't say much about when to define a search param there; if that's the official guidance, I'll at least put in a tracker on this topic.)
Lloyd McKenzie (May 01 2019 at 02:23):
That's what we have - hasn't been touched in 3+ years.
Eric Haas (May 01 2019 at 16:47):
So my thinking is that every element ( and extensions) gets and out of the box base SP that can be derivedFrom. Maybe I'm going down a rathole but I think is useful for conformance and testing to pinpoint what you must support at this level of detail of the sp and deriving sp from the standard promotes a heck of lot more interoperability than everybody creating custom sp on there own. This is less about usage and more about when is used they all look the same and have consistent names
Lloyd McKenzie (May 01 2019 at 16:51):
I don't think we should define anything we don't think most systems will support. It's easy enough for implementers to define their own if they need them. Defining them in bulk to save 20 minutes of development time isn't a good tradeoff.
Eric Haas (May 01 2019 at 17:05):
So
- I define sp -x as "foo"
- you define the same as "bar"
and they are defined similary but not the same and they do they same thing. I don't think that scenario is good
Eric Haas (May 01 2019 at 17:06):
naming and renaming things is a pain and I think it would be useful
Eric Haas (May 01 2019 at 17:06):
to have a catalog of sp's built into the resource
Lloyd McKenzie (May 01 2019 at 17:25):
Really, we need a differentiation between 'core' and 'extension' search parameters. However, even the extension ones shouldn't be auto-generated. Someone needs to think about what paths make sense, whether it should be compositional or not, what the appropriate type is, etc. And there are some things that just don't make sense to search.
Lloyd McKenzie (May 01 2019 at 17:25):
(E.g. Patient.contact.gender)
Last updated: Apr 12 2022 at 19:14 UTC
