Stream: fhirpath
Topic: FhirPath with reverse chaining
François Macary (Jul 23 2018 at 08:25):
Search context:
Catalogs implement the Composition resource and entries of a catalog are represented by CatalogEntry resources referenced by section.entry elements of the Composition. In the Catalog profile of Composition, section.entry is constrained to Reference(CatalogEntry).
I want to get all CatalogEntry resources referenced by section Hematology (LOINC 18723-7) of the catalog of id 4. Is the expression below syntactically correct and fit for this purpose?
GET [base]/CatalogEntry?_has:composition.where(id = 4).section.where(code.coding.where(system = %loinc and code = 18716-1))
Ewout Kramer (Jul 23 2018 at 11:23):
No, the URL-style query syntax is not integrated like this within FHIRPath.
The only way to do "anything" with http directly, is the resolve() call, but this has to resolve to a single URL, e.g. resolve('http://example.org/Patient/1').name.given.
Also, remember there's no concept of a "server" against which you execute the FHIRPath, it is evaluated against an (abstract) "instance", e.g. a single resource in FHIR.
Conceivably though, we could introduce a function http-get(string) that can return a bundle, which would be interpreted as a collection: httpget('http://example.org/Patient?name=macary')
In practice, you'd need more setup, since the server probably requires authentication and the like - all of this currently outside the scope of FHIRPath.
François Macary (Jul 23 2018 at 11:49):
Sorry Ewout, my topic title was maybe misleading.
My intent is not to embed URL-style syntax within FHIRPath but the other way round:
I understoodd that FhirPath is usable to express search parameters. So I thought I could leverage a fhirpath expression embedded in my search parameter, which happens to use reverse chaining.
My hope was that the fhirpath expression "composition.where(id = 4).section.where(code.coding.where(system = %loinc and code = xxxx-x))" would have specified the reverse chaining I wanted in my RESTful search: "get resources referenced by Hematology section of catalog 4."
I'm on the server side and my plan was to implement this search with this syntax.
If this does not work, then how is FHIRPath usable in search parameters?
Thank you.
Grahame Grieve (Jul 23 2018 at 11:54):
what we say is that the API names search parameters so that the server can prepare the index in advance. it doesn't have to, of course. but that's why named parameters.
Grahame Grieve (Jul 23 2018 at 11:55):
we also provide search parmaeter definitions that have fhirpath for the parameters so they can be built automatically.
Grahame Grieve (Jul 23 2018 at 11:55):
but that's private to the server, whether it wants to do that or not
François Macary (Jul 23 2018 at 14:38):
Thank you Grahame. I'm still struggling with search parameters.
So given my current purpose: Search for CatalogEntry resources referenced under section coded xxx of Composition/4
I might solve it by naming a new composite search parameter for the CatalogEntry resource , which captures the two values _id of the Composition resource and the code of section referencing.
My search would then look like this: GET [base]/CatalogEntry?in-catalog-section=4$18716-1
Sorry for being in the wrong stream, now.
Grahame Grieve (Jul 23 2018 at 22:22):
@Ewout Kramer I wonder if this is beyond our existing paradigm?
Lloyd McKenzie (Jul 24 2018 at 02:09):
Would we follow standard convention and allow "foo ' bar" and 'foo " bar' to be legal, but not "foo bar' or 'foo bar"?
Jean Duteau (Jul 24 2018 at 02:23):
I would think so. Basically, either of ' or " starts the string and you keep going until you find the 2nd occurrence of the character.
Grahame Grieve (Jul 24 2018 at 04:35):
yes that makes sense. but it's procedurally difficult
Ewout Kramer (Jul 24 2018 at 07:08):
Would we follow standard convention and allow "foo ' bar" and 'foo " bar' to be legal, but not "foo bar' or 'foo bar"?
I thought we fixed strings to always use 'xxxxx', since "yyyyy" is an escape for property names. Has that changed?
Grahame Grieve (Jul 24 2018 at 07:15):
no it hasn't but I'm finding that it's enduringly painful for me and others who are all confused.... wastes lots of my time
Ewout Kramer (Jul 24 2018 at 07:31):
@Ewout Kramer I wonder if this is beyond our existing paradigm?
You mean defining search parameters using a FHIRPath expression, where reverse chaining is involved? Yes that's outside, currently we have a single instance in scope - and so doing:
Composition.where(id = 4).section.where(...).entry.ofType(Reference).resolve().ofType(CatalogEntry) would only work if you already had the Composition in scope to begin with.
You'd need to switch to "Please bring all Compositions in scope, and then execute this". Feels like what CQL does with "context Patient", "context Population"....
Ewout Kramer (Jul 24 2018 at 07:36):
In general, the way CQL uses the "Retrieve" construct to kind of pre-load the evaluation context seems like a good way to do it: https://github.com/HL7/cql/blob/master/spec/2018May/02-authorsguide.adoc#retrieve
Grahame Grieve (Jul 24 2018 at 07:42):
well, actually, I don't think that we can describe what Francois wants with our current search paradigm? (forget the FHIRPath bit)
Christiaan Knaap (Jul 24 2018 at 08:49):
It is possible in the current Search framework to express exactly what @François Macary intended with his GET example but it is a bit ugly and requires a very specialized searchparameter.
A reverse chain (_has) can express two things:
1. The searchparameter that must chain the two resources together. In the example the most matching standard searchparameter for that is Composition.entry.
2. Filters on the referencing resource. In this example that is _id=4.
So you can express:
GET [base]/Catalogentry?_has:Catalog:entry:_id=4
That will return the requested CatalogEntry resources. But it will also include any resources referenced by entries in sections not having code http://loinc.org|18716-1.
So _has cannot express further filters to make a subselection of the references in the linking searchparameter (entry). And that is what is the intent here.
To solve that, you need a searchparameter that already expresses that filter, and use that in the _has. This would be a very specialized searchparameter Composition.hematology-entry, with (corrected) expression
Composition.section.where(code.coding.where(system="http://loinc.org" and code="18716-1")).entry
The resulting GET would then be:
GET [base]/CatalogEntry?_has:Catalog:hematology-entry:_id=4
Note: Catalog and CatalogEntry are not (yet?) resourcetypes as far as I know, but to connect to the question I used them nonetheless.
Brian Postlethwaite (Jul 25 2018 at 03:01):
I'm not a fan of a search parameter definition with a resolve in it, means that if the referenced item changes, it could change the search index value that I generated at the time. Have we done this anywhere?
Grahame Grieve (Jul 25 2018 at 03:05):
no
Brian Postlethwaite (Jul 25 2018 at 03:12):
phew, I didn't think we would have.
Last updated: Apr 12 2022 at 19:14 UTC
