Stream: questionnaire
Topic: FHIRPath-based population
Vladimir Smirnov (Oct 18 2018 at 16:33):
We are trying to implement form population along the lines of the FHIRPath-based Population in current draft IG. It specifies the sdc-questionnaire-sourceQueries extension containing a bundle of search queries.
What structure should such a bundle have? Does this mean we put a FHIR search string in Bundle.entry.request, one entry in bundle per questionnaire item to be populated?
The Questionnaire/{id}/$populate operation accepts resources to go into form fields in the "content" parameter. However, we want to keep some association between the resources and the fields they are intended for. One way of maintaining this is passing search results in a bundle of similar structure to the one with queries: for every entry containing a request, the Form Filler executes the search and places the result in Bundle.entry.resource. This way, for every form field, the search result would be located in the Bundle.entry at an index known in advance, and we could pre-generate FHIRPath queries against the bundle of search results for every questionnaire item at the time of authoring the questionnaire with its sourceQueries extension containing the bundle of queries.
This would work when a single resource is expected to result from the query, to go into a single instance of a questionnaire response item. But what if we want to get multiple search results, to populate a repeating form field? Some ways to accomplish this:
- To put the search results of a query as a nested bundle in Bundle.entry.resource. Nested bundles don't feel nice, but this lets us build FHIRPath queries against the bundle structure given in the sourceQueries extension.
- To put in the bundle multiple entries (one per search result) having the same query string. To populate a field, we select the entries having its corresponding query string, and extract values from their resources. This is fragile since it requires queries for every field to be unique.
- To put a custom extension in Bundle.entry, which would provide linkId of the item being populated. Now at least we don't use query strings as field identifiers.
- To reject the idea of passing all search results for the form in a single bundle, and instead pass the resources individually in the "content" parameter of $populate, but augment them with a similar extension stating the target linkId.
I am sure there must have been discussions on this matter in the working group, weren't there any recommendations?
Lloyd McKenzie (Oct 18 2018 at 21:50):
It's not necessarily one query per item, it's one query per set of information that needs to be available to populate the questionnaire. A simple Questionnaire might only need one query (possibly with includes) to grab all of the information needed to populate the questionnaire. The results of the queries will be available for FHIRPath to reach into and grab the relevant information to populate the different items within the Questionnaire. Our expectation is that forms often won't be well-aligned with the structure of resources, so we don't want to rely on such alignment in our extraction/population process. A lot of forms are formally tested instruments that can't be altered or are defined by people who don't know (or care) what impact their design choices have on alignment of the data with FHIR.
The search results will absolutely be a Bundle of Bundles - that's what the result would be to executing the Batch. And you would indeed use FHIRPath to navigate the results. This will be much more clear once we update the specification to actually have some example instances (and probably improve the documentation as well :>)
Brian Postlethwaite (Jun 08 2019 at 07:24):
Did this clarification get done, and any examples anywhere?
(looking to include it in Eric and My DevDays presentation)
Lloyd McKenzie (Jun 08 2019 at 14:01):
Examples? Not yet :(
Brian Postlethwaite (Jun 08 2019 at 14:15):
Looks like I have a job to do then.
Brian Postlethwaite (Jun 08 2019 at 14:15):
And you can review it too :yum:
Maybe during the let's build session.
Eric Haas (Jun 08 2019 at 15:44):
I was planning to demo the NLM tooling for extraction if i can get it to. Right now some glitches. Otherwise I will try To Stand up a simple copy and paste proof of concept app
Paul Lynch (Jun 10 2019 at 16:53):
@Brian Postlethwaite Depending on what kind of examples you are looking for, we might have some here. The ussg-fhp.json uses launchContext and initialExpression. The weight-height-questionnaire.json contains an example of "variable" (though the source data is brought in via observationLinkPeriod, so it is kind of a mix of obsevation-based and FHIRPath-based).
Last updated: Apr 12 2022 at 19:14 UTC
