-
Notifications
You must be signed in to change notification settings - Fork 160
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
Populate "path" property in FHIRPathNode implementations representing system values #3619
Comments
I also updated the javadoc (relates to #2153) because the user was confused about the FHIRPathNode API and I thought it could use further clarification. Signed-off-by: Lee Surprenant <[email protected]>
The previous commit set the path for Resource.id, Element.id, and Extension.url primitive values. This commit extends that to include *all* SystemValue nodes. Additionally Resource.id, Element.id, and Extension.url value nodes are now added to the context tree. Primitive value nodes named "value" are still kept out of the tree and are still only accessible through their parent's `getValue()` accessor. Signed-off-by: Lee Surprenant <[email protected]>
The FHIRPathPatch API is implemented via utilities in FHIRPathUtil. Both the FHIRPatchPatch API and the unerlying utility methods were designed to operate on FHIR nodes (FHIRPathResourceNode and FHIRPathElementNode). However, the delete API in particular is not strictly bound to paths that select FHIR nodes. Previously, calling delete on a path that selects one of these nodes would result in a NullPointerException. With the previous commit, it would instead become a no-op. With this commit, we will now attempt to remove the primitive value node and rebuild the parent accordingly. This allows users to remove fields like Resource.id and Element.id via FHIRPath and it even allows you to remove the value of primitive FHIR elements (e.g. Patient.active.value) in cases where those primitives already have an extension (otherwise they need to have a value). Signed-off-by: Lee Surprenant <[email protected]>
issue #3619 - populate 'path' field for SystemValueNodes in context tree
Info for executing the fhir-path cli jar can be found at https://github.com/IBM/FHIR/tree/main/fhir-path |
One of the primary motivations for this issue is to be able to work with the 'Element.id' attribute from our FHIRPathPatch engine. Previously we had some "interesting" behavior for this attribute where it would fight with the 'value' attribute on primitives. To verify that part of the fix I recommend the followings:
|
Per the above I posted the following resource:
Then I removed the
@d0roppe feel free to do some related testing |
seems to be working |
Is your feature request related to a problem? Please describe.
We have a requirement to remove the "id" property from certain elements of a resource. Consistent with other planned operations, we would find the targets using a FHIRPath expression and then remove them using FHIRPathUtil.delete(). FHIRPathUtil.delete() requires the path to the target, but the path() method returns null for FHIRPathStringValue objects returned from the FHIRPath evaluation.
Describe the solution you'd like
The path() method in FHIRPathStringValue objects and probably other FHIRPathSystemValue implementations should return the path to the node like it does for other implementations of FHIRPathNode.
Describe alternatives you've considered
For this particular scenario, we could use FHIRPath to find all the Element type objects in the tree and check each of them to see if the "id" value is populated. We would then update the parent object in a different manner.
Acceptance Criteria
1.
GIVEN [a FHIRPath expression that targets "id" or another system value field, such as "descendants().select(id)"]
AND [EvaluationContext evaluationContext = new EvaluationContext(some-resource)]
WHEN [FHIRPathEvaluator.evaluator().evaluate(evaluationContext, fhir-path-expression]
THEN [for each object returned, path() is non-null]
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: