FHIR Chat · FHIRPath Patch on uninitialized object/list · implementers

Stream: implementers

Topic: FHIRPath Patch on uninitialized object/list


view this post on Zulip Mikael Weaver (Dec 05 2021 at 22:52):

Hello! I'm working on a FHIRPath Patch implementation for our FHIR server. I've run into two related use cases where data needs to be added to a resource, but the target object or list isn't initialized. The specification page doesn't address proper behavior for this scenario, so my assumption is that the behavior is left up to the implementer. Is that correct? Also, any input on what the server should do for these scenarios?

Below are a couple of sample use cases. Thanks for the help!

Use Case 1: Adding a value to a nested object that doesn't exist.
The Patient has an identifier defined without a period. The user wants to be able to expire the identifier. Should the server initialize the period object that doesn't exist on the object or return an error?

{
    "resourceType": "Patient",
    "identifier": [
        {
            "use": "official",
            "value": "123"
        }
    ]
}
{
    "resourceType": "Parameters",
    "parameter": [
        {
            "name": "operation",
            "part": [
                {
                    "name": "type",
                    "valueCode": "add"
                },
                {
                    "name": "path",
                    "valueString": "Patient.identifier.where(use = 'official').period"
                },
                {
                    "name": "name",
                    "valueString": "end"
                },
                {
                    "name": "value",
                    "valueDate": "2021-12-01"
                }
            ]
        }
    ]
}

Use Case 2: Inserting a value into a list that doesn't exist.
A Patient resource exists without any identifiers. The user wants to add an identifier to the patient. Should the server initialize the identifier list or return an error?

{
    "resourceType": "Patient"
}
{
    "resourceType": "Parameters",
    "parameter": [
        {
            "name": "operation",
            "part": [
                {
                    "name": "type",
                    "valueCode": "add"
                },
                {
                    "name": "path",
                    "valueString": "Patient"
                },
                {
                    "name": "name",
                    "valueString": "identifier"
                },
                {
                    "name": "value",
                    "valueIdentifier": {
                        "system": "http://example.org",
                        "value": "value 3"
                    }
                }
            ]
        }
    ]
}

view this post on Zulip Lloyd McKenzie (Dec 06 2021 at 02:50):

It may be best to ask on #fhirpath

view this post on Zulip Mark Putke (Dec 06 2021 at 14:27):

Hello,

I couldn't find a proper way handling patches with certain elements with the implementation of hapi FHIR server as well. I think it's addressing the same issue here. Additionally the behavoir of JSON patches and patching with FHIRPath seems to be not equal.

I want to add a linkto the ressource Patient ressource. If there are no other link elements in this ressource, the server response status code is 400 with the message "parent of node to add does not exist".

Sample

[

    {
        "op": "add",
        "path": "/link/-",
        "value": {
            "other": {
                "reference": "Patient/108"
            },
            "type": "seealso"
        }
    }
]

The same for FHIRPath, but different behavior. This case returns a status code 200 but doesn't set the link.
Surprisingly it's working if I try to patch the element identifier instead.

<Parameters
    xmlns="http://hl7.org/fhir">
    <parameter>
        <name value="operation"/>
        <part>
            <name value="type"/>
            <valueCode value="insert"/>
        </part>
        <part>
            <name value="path"/>
            <valueString value="Patient.link"/>
        </part>
        <part>
            <name value="index"/>
            <valueInteger value="0"/>
        </part>
        <part>
            <name value="value"/>
            <valueLink>
                <other>
                    <reference value="Patient/108"/>
                </other>
                <type value="replaced-by"/>
            </valueLink>
        </part>
    </parameter>
</Parameters>

view this post on Zulip Lloyd McKenzie (Dec 06 2021 at 15:35):

@Grahame Grieve

view this post on Zulip Mikael Weaver (Dec 06 2021 at 18:07):

@Mark Putke for JSONPatch, it looks like the object must exist and be initialized according to the JSONPatch spec RFC 6902 4.1. The spec says "However, the object itself or an array containing it does need to exist, and it remains an error for that not to be the case". I would expect a result of HTTP 400 there. The behavior you are seeing with the FHIRPatch implementation looks incorrect - it should either result in a successful patch or an error.

view this post on Zulip Mikael Weaver (Dec 06 2021 at 19:09):

Lloyd McKenzie said:

It may be best to ask on #fhirpath

Thanks I'll ask over there in a bit.

view this post on Zulip Mikael Weaver (Dec 06 2021 at 21:05):

Conversation moved to #fhirpath here.

view this post on Zulip Grahame Grieve (Dec 07 2021 at 02:10):

hi Mikael. Good questions.

Case one is an error - the server should say something like "No content found at Patient.identifier.where(use = 'official').period when adding". This is defined in the spec when it says:

The FHIRPath statement must return a single element

but I agree it could be bit clearer.

For case #2, it's not an error - the path expression returns a single element, and it adds identifier to it.

I added your two test cases: https://github.com/FHIR/fhir-test-cases/blob/master/r4/patch/fhir-path-tests.xml#L1381

view this post on Zulip Grahame Grieve (Dec 07 2021 at 02:11):

oh. i'll go update the other thread

view this post on Zulip Mikael Weaver (Dec 09 2021 at 23:57):

Thank for the interpretation and test cases @Grahame Grieve! I have a bit more work to do for test case #2 then we'll have it fully working. I have a few more test cases that may be useful to add - I'll ping you here once they are merged.


Last updated: Apr 12 2022 at 19:14 UTC