Snapshot 3: Connectathon 32 Base

This page is part of the FHIR Specification (v5.0.0-snapshot3: R5 Snapshot #3, to support Connectathon 32). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3

3.2.5 FHIRPath Patch

FHIR Infrastructure icon Work GroupMaturity Level: 2Standards Status: Trial Use

This page defines a FHIR Parameters-based, syntax-agnostic patch mechanism where elements to be manipulated by the patch interaction are described using their FHIRpath names and navigation.

3.2.5.1 Operations

This table documents the FHIR Patch operations that may be used to specify changes to a resource:

Type Path Name Value Index source destination Details
add Path at which to add the content Name of the property to add Datatype to add at nominated place The content will be appended to the element identified in the path, using the name specified. Add can used for non-repeating elements as long as they do not already exist
insert Path of the collection in which to insert the content value (Datatype) to add at nominated place index at which to insert The content will be inserted into the nominated list at the index specified (0 based). The index is mandatory and must be equal or less than the number of elements in the list. Note: add is easier than insert at the end of the list
delete Path of the element to delete (if found) Only a single element can be deleted
replace Path of the element to replace value (Datatype) to replace it with
move Path of the collection in which to move the content list index to move from list index to move to Move an element within a single list

There are a few base rules that apply for all operations:

  • The FHIRPath statement must return a single element
  • The FHIRPath statement SHALL NOT cross resources using the resolve() function (e.g. like Observation.subject.resolve().identifier). resolve() SHALL only be used to refer to contained resource within the resource being patched. Servers SHALL NOT allow patch operations to alter other resources than the nominated target, and SHOULD return an error if the patch operation tries
  • The type of the value must be correct for the place at which it will be added/inserted. Servers SHALL return an error if the type is wrong
  • Servers SHALL return an error if the outcome of the patch operation is a not a valid resource
  • Except for the delete operation, it is an error if no element matches the specified path
  • Operations are applied in order, with each operation applied to the result of the previous patch operation

3.2.5.2 Parameters Format

The FHIRPath patch operations are encoded in a Parameters resource as follows:

  • Each operation is a Parameter named "operation"
  • Each operation has a series of parts, using the following parameter names from the table above with these types:
Parameter Type
type code
path string
name string
value *
index integer
source integer
destination integer

Here is an example of adding an element: 

<Parameters xmlns="http://hl7.org/fhir">
  <parameter>
    <name value="operation"/>
    <part>
      <name value="type"/>
      <valueCode value="add"/>
    </part>
    <part>
      <name value="path"/>
      <valueString value="Patient"/>
    </part>
    <part>
      <name value="name"/>
      <valueString value="birthDate"/>
    </part>
    <part>
      <name value="value"/>
      <valueDate value="1930-01-01"/>
    </part>
  </parameter>
</Parameters>

3.2.5.2.1 Anonymous Types

Only some named datatypes (see the list) are allowed to be used directly in parameters. In order to add or insert other kinds of types - including anonymous elements (e.g. Observation.component, Timing.repeat), the content is defined by defining the name as described above, and instead of providing a value, a set of parts that are values are provided. Here is an example: 

<Parameters xmlns="http://hl7.org/fhir">
  <parameter>
    <name value="operation"/>
    <part>
      <name value="type"/>
      <valueCode value="add"/>
    </part>
    <part>
      <name value="path"/>
      <valueString value="Patient"/>
    </part>
    <part>
      <name value="name"/>
      <valueString value="contact"/>
    </part>
    <part>
      <name value="value"/>
      <part>
        <name value="name"/>
        <valueHumanName>
          <text value="a name"/>
        </valueHumanName>
      </part>
    </part>
  </parameter>
</Parameters>

This pattern repeats as deep as necessary.

There is a set of test cases for implementers as part of the Test Case Downloads.