Stream: implementers
Topic: GET query -- only entries that conform to a profile
John Moehrke (Apr 24 2017 at 17:05):
Is there a way in a GET to indicate to the server that the client wants only entries that conform to a named profile?
John Moehrke (Apr 24 2017 at 17:15):
I recognize the _profile query parameter... but how does the fact that the resources on the server 'are' compliant with that profile known?
Josh Mandel (Apr 24 2017 at 17:39):
Supplying an explicit parameter presumably only returns resources that include the specified profile annotation -- but how that annotation got there is a server dependent phenomenon (so some servers could faithfully pass through all client-originated annotations even if they were lies; other servers could validate client annotations; and still other servers could proactively apply new annotations based on analysis of a given resource)
John Moehrke (Apr 24 2017 at 17:41):
yes, that is the non-deterministic problem we are struggling with... that and how do we specify that the server MUST validate all Create/Update actions against our profile.
Lloyd McKenzie (Apr 24 2017 at 17:54):
You can do all sorts of things with ImplementationGuide text. But it's not something you can currently express in a CapabilityStatement
John Moehrke (Apr 24 2017 at 18:40):
Im not even sure how to express this need in narrative business requirement. Take the case where a profile on Location wants to assure that the Location.name must be filled. How do I represent that a Server shall not return entries that have Location.name empty? That is to say, how does a client indicate that they don't want Locations that have no Location.name value?
John Moehrke (Apr 24 2017 at 18:51):
The normal HTTP GET expectation is that the server returns results that match the query parameters that it understood. These results might or might not have profile conformance. These results might even be more than the client wanted, due to the server not implementing the query prameters provided.
Grahame Grieve (Apr 24 2017 at 18:54):
location:missing=false
John Moehrke (Apr 24 2017 at 19:00):
interesting.. but are you serious? A client that wants this needs to include each parameter cardionality requirement? What about elements that don't have a parameter?
Grahame Grieve (Apr 24 2017 at 19:02):
I don't know whether I'm serious. What you are asking is.... difficult. Does the client really want to ignore locations that have no name?
Grahame Grieve (Apr 24 2017 at 19:02):
every time I've gamed this out in reality, it's always come back to, the application wishes to live in a reality where all locations have a name.
Grahame Grieve (Apr 24 2017 at 19:03):
sometimes, that's achievable, and we have a conformance mechanism to deal with that.
John Moehrke (Apr 24 2017 at 19:03):
the xample of name is an example of a constraint... I could have been more persuasive on the need for the constraint... but ultimetly there is a general solution needed
Grahame Grieve (Apr 24 2017 at 19:03):
but simply naming a profile, and expecting the server to magically figure out how to filter records for conformance to the profile... it's always seem computationally unfeasible to us
John Moehrke (Apr 24 2017 at 19:04):
I don't like that either... I have tried to argue that the constaints are not something one applys to a Query; they are rules you apply on Create/Update.
John Moehrke (Apr 24 2017 at 19:05):
but... I needed to ask if there was a solution... because right now we are profiling only the GET side, not Create/Update....
Brian Postlethwaite (Apr 26 2017 at 08:54):
And for the location resource, there are some types of locations where a name just doesn't make sense, specifically where they are only recording the geo-code co-ordinates. So the constraint to force a name would result in it being filled with junk.
John Moehrke (Apr 26 2017 at 12:17):
The question is not specific to Location resource... it is a question about any Resource... It is not specific to Location.name, that was just an example of a string that some application may want not empty. The question is, is there a way a client can ask that results be constrained to only results that are compliant to a specified Profile? -- It seems not, and I am not thinking this is an important need. I just didn't want to ignore a capability that exists when there was moderate interest in using that capability, if it existed.
Brian Postlethwaite (Apr 26 2017 at 20:52):
(I have a similar use case where I want to filter the returned with a profile, to get a similar effect to _elements or _summary, where the profile is used to mask the properties - I believe some others have done something similar)
Chris Grenz (May 06 2017 at 10:26):
@John Moehrke We implemented this (partially) as part of our profile governed API system. GET /patient?_profile:evaluate=http://example.com/fhir/some-profile asks the server to ensure that returned resources meet the profile. We implemented by parsing the profile and pulling out "limiting" parts of the profile such as max=0, fixed[x], minValue[x], etc. and converting those parts to persistence layer queries (ElasticSearch in our case). The resulting candidates are then washed thru the validator if needed (additional expressions to evaluate).
Chris Grenz (May 06 2017 at 10:27):
It's smart enough to "build" on pre-validated content. E.g. since all Patients already conform to the standard profile, no expressions from that profile are loaded. In our case, they already conform to the enterprise profile as well, so that's even fewer checks.
John Moehrke (May 06 2017 at 10:31):
I think we should use this as an example of a more common need. Is this a need that is best served by breaking the resource into more 'right sized' Resource? Is this need that should be built into a more reusable pattern? etc. Seems like a job for FHIR-I and Security to work together.
Chris Grenz (May 06 2017 at 10:41):
Our use case is more about semantic definition - we create sets of profiles for integrated contexts, usually a clinical specialty, and use those profiles to govern communication with the FHIR server for app access and ultimately for analytics.
Last updated: Apr 12 2022 at 19:14 UTC
