Stream: implementers
Topic: extensions in _summary mode
Michael Hansen (Jul 18 2019 at 04:19):
A few of us (@Ewout Kramer , @James Agnew , @Josh Mandel ) have been having a discussion about whether or not nested extensions on fields labeled as isSummary=true should be included when using the _summary=true search parameter. For example in the following Patient address:
"address": [
{
"extension": [
{
"url": "http://fhir.ufp/StructureDefinition/planet",
"valueString": "Earth"
}
],
"use": "home",
"type": "both",
"line": [
"Milchstrasse 42"
],
"city": "Spöck",
"postalCode": "76297",
"country": "DE"
}
],
should the planet extension be included in summary view?
The discussion started because some servers include the rest.security.extension content in /metadata and some do not. SMART on FHIR client libraries query the capability statement to learn about the authorize and token endpoint and some default to doing this in summary mode to avoid pulling down a very large capability statement, e.g. on a mobile device. It is perfectly understandable why they would want to do it that way.
The question is now if it is reasonable for a client to expect that auth information is included in summary view?
The spec (https://www.hl7.org/fhir/search.html#summary) says "This subset SHOULD consist solely of all supported elements that are marked as "summary" in the base definition of the resource(s)", but the question is whether any nested extensions on elements labeled summary should be included? And the spec also includes the statement: "Implementation Note: There is some question about the inclusion of extensions in the summary. Additional rules may be made around this in the future.", so it is at least somewhat ambiguous.
Servers that are based on the .NET FHIR API (Vonk, Microsoft FHIR Server, etc) don't include extensions in summary view (even nested extensions on elements that are labeled as is summary are excluded). Servers based on HAPI FHIR don't include extensions on resources (e.g. an extension on address is excluded in summary), but due to a bug that was discovered over the course of our discussion, it just happened to include them on the capability statement, but not others. Since the SMART sandbox is based on HAPI, several SMART on FHIR client libraries now include a dependency on this bug. The test.fhir.org server appears to include extensions nested on isSummary elements. The EMR based FHIR from Cerner, Epic, and AllScripts don't appear to support _summary at all.
It would seem that it would at least be not recommended for a client to depend on this behavior, but some do nonetheless. We were wondering what the correct path forward is?
1. Introduce the "bug" (if that is what it is) in all servers? If yes, only for capability statement?
2. "Fix" all the client libraries?
3. Update the spec to be explicit about the expected behavior one way or another?
4. Some combination of all of the above.
5. ??
@Grahame Grieve , would love to hear your thoughts on this?
@Kurt Ericson what does the GCP FHIR service do?
Ewout Kramer (Jul 18 2019 at 12:05):
Thanks @Michael Hansen, great summary of our discussion.
Grahame Grieve (Jul 18 2019 at 12:06):
I deliberately ensured that those extensions are in the summary.
Grahame Grieve (Jul 18 2019 at 12:07):
the smart-app-launch spec is moving away from the extensions to known url based discovery. Which I prefer myself now
Grahame Grieve (Jul 18 2019 at 12:07):
in the mean time, I will keep my server returning those extensions in summary mode, irrespective of whether I return others or not
Grahame Grieve (Jul 18 2019 at 12:08):
I don't know what the correct answer should be
Josh Mandel (Jul 18 2019 at 13:55):
I think in the near term, updating the two SMART libraries with this behavior (Python and Swift) to avoid depending on _summary would help -- and in the process, updating them to also use /.well-known when available. FYI @Pascal Pfiffner and @Harold Solbrig.
Josh Mandel (Jul 18 2019 at 13:58):
For r5, I think we should pin down expectations for _summary to resolve this ambiguity. (My preference would be to say that complex extensions aren't included -- but clarify that simple extensions are, since they behave as "data type properties" )
Josh Mandel (Jul 18 2019 at 13:59):
(And we might clarify that modifier extensions of any nesting level should be included; I'm not sure.)
Josh Mandel (Jul 18 2019 at 14:01):
During this discussion, a question also came up about the _elements query parameter. The spec makes it unclear whether nested paths are allowed. (I assume not, though HAPI responds differently than Grahame's server for /metadata?_elements=rest.security)
Lloyd McKenzie (Jul 18 2019 at 15:16):
I guess a base question is whether _summary means that other elements are absolutely prohibited, or merely that they should be absent
Paul Church (Jul 18 2019 at 15:22):
GCP FHIR has not yet implemented _summary=true (just data/text). If I had to guess based on how the server is generally implemented, we will probably default to including nested extensions on summary elements.
Paul Church (Jul 18 2019 at 15:22):
Related question, does _summary also summarize contained resources, or exclude them?
Lloyd McKenzie (Jul 18 2019 at 15:31):
That's a good question @Paul Church. Can you submit a change request for us to put an answer to this into the core spec (once we figure out what the answer is :>)
Paul Church (Jul 18 2019 at 15:43):
Pascal Pfiffner (Jul 18 2019 at 21:39):
Acknowledging that this pattern has cascaded into what it is today because of the early behavior of what is returned with _summary in the early SMART sandboxes. Agree with Josh that it would be good to have the Python @Harold Solbrig and Swift @Dave Carlson libraries stop issuing _summary when loading the capability statement and to add support for .well-known in a second step.
Michael Hansen (Jul 19 2019 at 01:46):
Thanks for chiming in everybody. For Swift (@Dave Carlson), I added this issue https://github.com/smart-on-fhir/Swift-FHIR/issues/26 the other day. In case you are tracking it.
Patrick Narkinsky (Jul 13 2021 at 13:48):
Is there any standard way to represent rules for required search parameters in the capability statement? What I mean is something like "For the Patient resource, you must provide EITHER "first name + last name + DOB" OR "first name + last name + phone number" OR "social security number"? If not, would an extension be appropriate?
Lloyd McKenzie (Jul 13 2021 at 14:26):
There's this: https://build.fhir.org/extension-capabilitystatement-search-parameter-combination.html
Last updated: Apr 12 2022 at 19:14 UTC
