Stream: questionnaire
Topic: Definition-based extraction with multiple resources
Jing Tang (Mar 02 2022 at 15:21):
When using Definition-based extraction to extract multiple resources, what's the best way to distinguish them in the result set? It seems a little "fickle" to rely on the order of the extracted resources. e.g. Should we use a name field in the extraction context?
Brian Postlethwaite (Mar 02 2022 at 21:37):
The resulting operation output is just a bundle of resources, so not sure where naming comes into it?
Lloyd McKenzie (Mar 03 2022 at 02:55):
What's your objective in "distinguishing" them?
Jing Tang (Mar 03 2022 at 17:12):
I think it depends on what we believe the application/developers should be able to do with the result set. In the most generic way, yes the result is just a bundle of resources and the application should probably save all of them to a server indistinguishably. But the application may have some knowledge of the expected resources, for example there might be two observations and they want to take the one that's about pulse oximetry. In this case shouldn't there be some facility for the developer/application to distinguish the resources? A name field in the extraction context or something similar? Is this the right way to think about it? Thanks.
Lloyd McKenzie (Mar 03 2022 at 19:02):
The Bundle that results would be a transaction Bundle. The receiver doesn't really have a choice of taking some and not others - at least not if they're processing the Bundle according to the rules. They can figure out which Observation is the pulseOx by doing a search by code once the data is stored.
Brian Postlethwaite (Mar 03 2022 at 20:27):
The spec doesn't actually dictate what to do with that bundle that is produced from the $extract, the caller of that operation will make that decision.
Jing Tang (Mar 14 2022 at 14:38):
Brian Postlethwaite said:
The spec doesn't actually dictate what to do with that bundle that is produced from the $extract, the caller of that operation will make that decision.
thanks this makes sense - i think the question here is that it's quite hard for the caller of that operation to make that decision without any hints on which resources are corresponding to which extraction contexts in the questionnaire
Paul Lynch (Mar 14 2022 at 14:44):
In your example about the application wanting the Observation that is "about pulse oximetry", wouldn't looking at Observation.code be a way for the application to find that one?
Jing Tang (Mar 14 2022 at 14:44):
for example, in this page https://developer.commure.com/docs/apis/sdc/examples/ there're examples with named contexts. is this something we should/can use?
Lloyd McKenzie (Mar 14 2022 at 15:38):
I'm not really following the use-case. What sort of traceability are you wanting and why? You don't need any traceability from 'question' to Observation in order to be able to search the resulting Observations.
Last updated: Apr 12 2022 at 19:14 UTC
