Retreival of Resource Graphs FHIR Infrastructure Proposal

From HL7Wiki
Revision as of 16:54, 23 September 2013 by Rene spronk (talk | contribs) (→‎Discussion)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


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.


  • 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.


  • 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?