-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support bundle-local reference resolution from the FHIRPath resolve function #3216
Comments
Hi @abedultamimi, can you give a little more info about what you're trying to do and where? What does the reference in question look like that you're trying to resolve? Our FHIRPath implementation has a built-in function registry. The default resolve function doesn't actually retrieve any resources but instead returns a placeholder so that most expressions can be evaluated without making network connections under the covers. Ensure your |
Hi @lmsurpre , Thanks for taking time to review this, my intention is to have this validated resolving other bundle entry. Assuem that i have a bundle of 2 entries like the below:
And im having a MedicationRequest.subject as "Patient/123" Xyz.com is an arbitrary value not equal to fhir server base url. Thanks Again |
Hi @abedultamimi sorry for the delay. I think the answer is that our current ResolveFunction implementation does not support the "Resolving references in Bundles" algorithm outlined at https://www.hl7.org/fhir/bundle.html#references I'm debating between: Let me know if you have a preference. I will do A if we don't hear back soon. |
This commit also adds support for the `resource:` scheme in our Bundle validation. This scheme is used in the SMART health cards spec and so I think it makes sense to explicitly allow it. This PR does *not* add support for reference rewriting for this `resource:` scheme at present, but I think that is a logical follow-on for issue #2512. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
This commit also adds support for the `resource:` scheme in our Bundle validation. This scheme is used in the SMART health cards spec and so I think it makes sense to explicitly allow it. This PR does *not* add support for reference rewriting for this `resource:` scheme at present, but I think that is a logical follow-on for issue #2512. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
This commit also adds support for the `resource:` scheme in our Bundle validation. This scheme is used in the SMART health cards spec and so I think it makes sense to explicitly allow it. This PR does *not* add support for reference rewriting for this `resource:` scheme at present, but I think that is a logical follow-on for issue #2512. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
In addition, this commit adds support for the `resource:` scheme in our Reference type checking / reference value validation. This scheme is used in the SMART health cards spec and so I think it makes sense to explicitly allow it. I thought that I would need to do additional logic for supporting reference rewriting for this scheme but, based on the test I added to FHIRRestHelperTest, apparently not...we just needed to let it past our parser. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
@abedultamimi I believe this limitation is now addressed in our |
Closing due to lack of response. We believe this is covered sufficiently in the updated ResolveFunction implementation to be shipped with 4.11. |
entry.first().resource.eventCoding.code='medication-dispense' implies entry.first().resource.focus.all( $this.resolve() is MedicationDispense)
i'm trying this constraint but without any luck, any idea how resolve works in ibm fhir. i also tried:
entry.first().resource.eventCoding.code='medication-dispense' implies entry.first().resource.focus.all( resolve() is MedicationDispense)
The text was updated successfully, but these errors were encountered: