-
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
Bundle transaction processing should replace all local references, not just ones that start with "urn:" #2512
Comments
This should be taken care of in #1869. Need to double-check the implementation. |
#1869 was closed, but I don't think we got this one in there. Sound right, @punktilious ? |
The scope of this issue is to replace all local references (not just those starting with the
|
Signed-off-by: Mike Schroeder <mschroed@us.ibm.com>
Signed-off-by: Mike Schroeder <mschroed@us.ibm.com>
Signed-off-by: Mike Schroeder <mschroed@us.ibm.com>
I posted the following transaction bundle (adapted from the a smart health card example):
I expected the transaction to be process and for the patient references in resource:1 and resource:2 to be replaced with the server-assigned id for resource:0. Instead, I got a 400 Bad Request:
I think what is happening is we're doing our reference type validation before rewriting the references. |
If we agree that we should support transaction bundles like this one, here's the simplest solution I could think of:
|
Robin brought up a different option which would be to make our parse validation smarter about what is a valid bundle...probably by making it conditional on the type of bundle (e.g. special reference type checking for bundles of type |
neither of those options are real simple/clean. Bundle parse validation actually happens in the FHIRProvider.readFrom (a JAX-RS provider for the application/fhir media types). To skip parse validation there would require some special-case logic where we introspect the uriInfo and take special action on a post the base url. Bleh. Making our parse validation smarter isn't a real simple win either because the ValidationSupport.checkReferenceType calls are in the individual resource types and backbone elements that have Reference data types and those methods are clueless about whether they happen to be getting parsed/validated as part of a larger batch/transaction bundle or not. To be honest, the option I'm leaning most towards now is moving reference type checking from parse validaton to secondary validation (FHIRValidator)...then it should be easier to control the behavior using either of the options presented above. |
Before going much further with this, I decided to re-read the latest proposed wording on bundle reference resolution: https://jira.hl7.org/browse/FHIR-29271?focusedCommentId=183020&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-183020 To me, this wording makes it more clear that if you have a fullUrl that doesn't begin with I decided to ask for further clarification at |
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>
Per discussion at https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Allowed.20uri.20schemes.20for.20Bundle.2Eentry.2EfullUrl.20and.20referenc.2E.2E.2E/near/271636029 We'll still reject literal reference values that begin or end with `:` and anything that looks like a "relative" URL path but doesn't follow the FHIR REST URL Pattern (e.g. a literal value like "123" with no scheme prefix). I also provided some algorithm examples in a comment and added a single local Bundle reference resolution test for the Bundle-in-a-Bundle case. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Closing after successful QA testing with the following transaction bundle:
|
Is your feature request related to a problem? Please describe.
From https://www.hl7.org/fhir/http.html#trules
Today, the IBM FHIR Server only updates literal references when they start with the "urn:" prefix.
Describe the solution you'd like
Update all literal references in the bundle when they match a fullUrl in the bundle that is associated with a resource being POSTed.
To determine whether a literal reference needs updating or not, we should follow the guidance at
https://www.hl7.org/fhir/bundle.html#references and I believe that we already have code for this.
Describe alternatives you've considered
Acceptance Criteria
GIVEN a transaction bundle with resources A and B
AND resource A is a POST
AND resource B is a POST or PUT with a literal relative reference to the fullUrl for resource A
WHEN the bundle is posted to the server
THEN the literal reference in resource B is updated to the assigned resource id of resource A
GIVEN a transaction bundle with resources A and B
AND resource A is a POST
AND resource B is a POST or PUT with a literal absolute reference to the fullUrl for resource A
WHEN the bundle is posted to the server
THEN the literal reference in resource B is updated to the assigned resource id of resource A
Additional context
The text was updated successfully, but these errors were encountered: