R4 Draft for Comment

This page is part of the FHIR Specification (v3.2.0: R4 Ballot 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

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

This page documents how the Parameters resource is used to define a set of FHIRPath based patch 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
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 must be equal or less than the number of elements in the list
delete Path of the element to delete 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 elements from the resource being modified. e.g. a FHIRPath could cross resources like Observation.subject.resolve().identifier. 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

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>

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.