Release 5 Preview #1

This page is part of the FHIR Specification (v4.2.0: R5 Preview #1). 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.1.5 FHIRPath Patch

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

This page documents how the Parameters resource is used to define a set of FHIRPath based patch operations.

3.1.5.1 Conceptual FHIRPath Operations

This table documents the FHIRPath 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 Data type 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 (Data type) 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 (Data type) 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.1.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.1.5.2.1 Anonymous Types

Only some named data types (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.