This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Retreival of Resource Graphs FHIR Infrastructure Proposal"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {{FHIR Discussion Page}} | ||
| + | [[Category:Active FHIR Discussion]] | ||
==Summary== | ==Summary== | ||
| Line 13: | Line 15: | ||
* Grahame: Did you look at the _include parameter [http://www.hl7.org/implement/standards/fhir/query.htm#return see here] ? I think you want a similar parameter that works backwards instead of forwards, right? | * Grahame: Did you look at the _include parameter [http://www.hl7.org/implement/standards/fhir/query.htm#return see here] ? I think you want a similar parameter that works backwards instead of forwards, right? | ||
* [[User:Rene spronk|Rene spronk]] Hadn't seen that option.. yes, a _reverseinclude=* option (or whatever name seems appropriate) would have the intended effect. _reverseinclude would (if similar to include) also allow for inclusion of specific resource types that have a reference to a resource - neat feature. | * [[User:Rene spronk|Rene spronk]] Hadn't seen that option.. yes, a _reverseinclude=* option (or whatever name seems appropriate) would have the intended effect. _reverseinclude would (if similar to include) also allow for inclusion of specific resource types that have a reference to a resource - neat feature. | ||
| + | * Grahame: discussion in committee. I was thinking of something like _include-origin=[x] where [x] would be * or a comma-delimited list of the resource types of interest | ||
| + | * Rene: just to make sure: I guess/hope that would include the option of specifying 'Observation.subject' for [x] to denote that we're asking for inclusion of any Observation resources that have a ''subject'' link to a certain patient resource. | ||
| + | ** Although we'll have to watch scope creep: before long the query 'give me all observations, findings and conditions created during the past 6 months for subject patient X' is 1 single GET using the newly proposed _include-origin option, thus effectively replacing queries such as 'get observations with query parameter patient=x'. Is it desirable to allow for such flexibility, or not? | ||
Latest revision as of 16:54, 23 September 2013
Summary
Add a mechanism to FHIR that allows one to query for specific sets of related resources. The return structure should be a bundle of resources.
Examples:
- For patient/@1 , give me a bundle with all resources that reference (inclusive of any references in extensions) patient/@1. Some of these resources are associated with the wrong patient, so I need to move them to the correct patient.
- Query parameters: resource id, potentially a timeframe of creation time or last update
- Rene spronk I tried doing this client side, but that's simply not doable in a production environment for performance reasons.
- Note that (once we have such functionality) it could be used recursively: e.g. from patient/@1 to (observation/@5 and observation/@7), and from observation/@7 to xyzresource/@8.
- For patient/@1 (which has status active=false), give me a bundle with all resources that reference (inclusive of any references in extensions) patient/@1. This so I can update all references to patient/@1 to the 'active version thereof' which is patient/@2.
Discussion
- Grahame: Did you look at the _include parameter see here ? I think you want a similar parameter that works backwards instead of forwards, right?
- Rene spronk Hadn't seen that option.. yes, a _reverseinclude=* option (or whatever name seems appropriate) would have the intended effect. _reverseinclude would (if similar to include) also allow for inclusion of specific resource types that have a reference to a resource - neat feature.
- Grahame: discussion in committee. I was thinking of something like _include-origin=[x] where [x] would be * or a comma-delimited list of the resource types of interest
- Rene: just to make sure: I guess/hope that would include the option of specifying 'Observation.subject' for [x] to denote that we're asking for inclusion of any Observation resources that have a subject link to a certain patient resource.
- Although we'll have to watch scope creep: before long the query 'give me all observations, findings and conditions created during the past 6 months for subject patient X' is 1 single GET using the newly proposed _include-origin option, thus effectively replacing queries such as 'get observations with query parameter patient=x'. Is it desirable to allow for such flexibility, or not?
