Resolve FHIR bundle resource references :

[Lakshmi Gowrishankar]

Hi,

I have a bundle which has multiple resources like medication data, Observation data and Encounter in the same bundle. Having References for these resources within the same bundle.
Example bundle is here:

Do I have a way programatically to resolve these references? 

Regards,

Lakshmi G

[Josh Mandel]

Sure thing. Are you using the SMART reference client? If so you might want to check out the "resolveReferences" feature in "fhirOptions" for your search. See https://docs.smarthealthit.org/client-js/client.html for details.

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smart-on-fhir/7d4db11c-e894-4df8-906c-42a95d64fe86%40googlegroups.com.

[Dave Carlson]

Hi Josh,

I am using this SMART client and "resolveReferences" works great for standalone resources.  However, I have not found a way to resolve or retrieve contained references, e.g. Medication contained within MedicationDispense.  The doc says:
    This option does not work with contained references (they are “already resolved” anyway).

When I do include:

   resolveReferences: ["medicationReference", "subject", "performer.0.actor"] })

The resulting object includes the entire MedicationDispense object inlined for any of the references that are contained.  I am using the latest release and FHIR R4.

Thanks for any help you can provide!

Dave

To view this discussion on the web visit https://groups.google.com/d/msgid/smart-on-fhir/CANSMLKFgF_pUNsamVwYhmh_-PY%3DxVPogwkRiq0Q%3DVhWLb7kmAQ%40mail.gmail.com.

[Josh Mandel]

Thanks Dave! If you are looking at inline results, should I assume that you are using the "graph" option alongside "resolveReferences" (the default behavior)? What happens if you try turning "graph" off? Overall, it would be great to create an issue in at https://github.com/smart-on-fhir/client-js/issues showing an example of a complete invocation, along with your expected output versus the output you are seeing instead.

[Dave Carlson]

Thanks, Josh.  While working out an example for the issue, I discovered that this problem was a side effect for a workaround to another issue.  I am new to this framework and scrambling to get a demo working for a HIMSS kiosk.  More on my situation:

Contained vs standalone Medication resources is a good, common example that should be supported, either within MedicationDispense (my use case) or MedicationRequest.  I believe US Core explicitly allows for either approach in MedicationRequest.  So, a client does not know in advance which approach may be found within a query.   My query looks like this (with additional search params that I omitted):

      return pdmpClient.request("MedicationDispense,

          { pageLimit: 0, flat: true,

            resolveReferences: ["medicationReference", "subject", "performer.0.actor"] })

When using all standalone references, this works as expected.  If one of the references is contained then I get a runtime 400 error where the framework is attempting to search on the #xyz reference, e.g. the 400 error on a URL similar to this: https://myserver.com/fhir/#pdmp-med-mae-1

I will submit an issue with example resource bundle, but can you suggest a workaround?  My previous message with incorrect inlining of resolution was because I had attempted a workaround for the real issue by appending a resource type to the base url, e.g. 

pdmpClient = new FHIR.client(endpoint+"/MedicationDispense");

Obviously not the right solution, but it removed the 400 error if I used a query string without resource type.  But then the resolution of contained "#id" simply returned the full base resource.  No runtime error, but incorrect result.

Thanks!

  Dave

[Vladimir Ignatov]

Hi Dave,

I just want to point out that on a high level, the purpose of the resolveReferences option is to automatically download stuff (referenced resources)  and give them back to you. With the contained references, that additional information is already included in the response. That is why the docs state that "This option does not work with contained references (they are “already resolved” anyway)".

The "resolveReferences" option does not control the sever response and is not able to instruct a FHIR server to not include contained references. The assumption here is that once you get a response, you can check for presence  of inline contained references and if such are found, do whatever you need to do with them. The client.getPath() function might be useful for that because it can query deeply nested paths without throwing exceptions if an intermediate path does not exist.

Hope that helps,

Vlad

On Feb 20 2020, at 1:28 pm, Dave Carlson <dcar...@xmlmodeling.com> wrote:

Thanks, Josh.  While working out an example for the issue, I discovered that this problem was a side effect for a workaround to another issue.  I am new to this framework and scrambling to get a demo working for a HIMSS kiosk.  More on my situation:

Contained vs standalone Medication resources is a good, common example that should be supported, either within MedicationDispense (my use case) or MedicationRequest.  I believe US Core explicitly allows for either approach in MedicationRequest.  So, a client does not know in advance which approach may be found within a query.   My query looks like this (with additional search params that I omitted):

      return pdmpClient.request("MedicationDispense,

          { pageLimit: 0, flat: true,

            resolveReferences: ["medicationReference", "subject", "performer.0.actor"] })

When using all standalone references, this works as expected.  If one of the references is contained then I get a runtime 400 error where the framework is attempting to search on the #xyz reference, e.g. the 400 error on a URL similar to this: https://myserver.com/fhir/#pdmp-med-mae-1

I will submit an issue with example resource bundle, but can you suggest a workaround?  My previous message with incorrect inlining of resolution was because I had attempted a workaround for the real issue by appending a resource type to the base url, e.g. 

pdmpClient = new FHIR.client(endpoint+"/MedicationDispense");

Obviously not the right solution, but it removed the 400 error if I used a query string without resource type.  But then the resolution of contained "#id" simply returned the full base resource.  No runtime error, but incorrect result.

Thanks!

  Dave

To view this discussion on the web visit https://groups.google.com/d/msgid/smart-on-fhir/CAMCPe65nxPQMeRPMzWN-DYNuP4G2BUVSp9jpbjrt7g93q4Kpaw%40mail.gmail.com.

[Dave Carlson]

Hi Vlad,

Yes, I understand the purpose of resolveReferences, and it works very well.  The problem lies when several reference in my resource *may* be contained and I don't have any control over the source data structure.  Also, in my situation, some endpoints might use all remote references and another all contained.  This could be a problem for any client app retrieving MedicationRequest based on US Core and resolving medicationReference. 

Because the current implementation for resolveReferences will throw a runtime exception whenever it encounters a contained reference, I cannot use resolveReferences for any of my elements.  I'll need to inspect each reference and either retrieve the contained, or call another server request for each of the remote references.  Could resolveReferences check for a "#" prefix to ignore contained links, and then proceed with current logic otherwise?  Then I can inspect and retrieve only contained references using a "#id".

Thanks,

  Dave

[Vladimir Ignatov]

Sure. Sounds like a good idea. Please open an issue and include those bundle examples so that we have something to test with.

Thanks,

Vlad

On Feb 20 2020, at 3:12 pm, Dave Carlson <dcar...@xmlmodeling.com> wrote:

Hi Vlad,

Yes, I understand the purpose of resolveReferences, and it works very well.  The problem lies when several reference in my resource *may* be contained and I don't have any control over the source data structure.  Also, in my situation, some endpoints might use all remote references and another all contained.  This could be a problem for any client app retrieving MedicationRequest based on US Core and resolving medicationReference. 

Because the current implementation for resolveReferences will throw a runtime exception whenever it encounters a contained reference, I cannot use resolveReferences for any of my elements.  I'll need to inspect each reference and either retrieve the contained, or call another server request for each of the remote references.  Could resolveReferences check for a "#" prefix to ignore contained links, and then proceed with current logic otherwise?  Then I can inspect and retrieve only contained references using a "#id".

Thanks,

  Dave

[Dave Carlson]

Thanks, Vlad.  I will create an issue with attached test bundle later today.

Dave