The typical use case would look like this:
Download resources from a server with fhir_search()
Crack to wide format them with fhir_crack()
Do something to values (e.g. some kind of anonymization)
Translate the data back into FHIR resources with fhir_build_bundle()
Post the resources to a server
A FHIR bundle that can be POSTed to a server is usually of type transaction
or batch
. Each entry of these bundles consists of the resource itself
as well as an instruction for the server of what to to with the resource. A very simple example looks like this:
<Bundle>
<type value="transaction"/>
<entry>
<resource>
<Patient>
<id value="id1"/>
<address>
<city value="Amsterdam"/>
<country value="Netherlands"/>
</address>
<name>
<given value="Marie"/>
</name>
</Patient>
</resource>
<request>
<method value="POST"/>
<url value="Patient"/>
</request>
</entry>
<entry>
<resource>
<Patient>
<id value="id2"/>
<address>
<city value="Paris"/>
<country value="France"/>
</address>
<name>
<given value="Anne"/>
</name>
</Patient>
</resource>
<request>
<method value="POST"/>
<url value="Patient"/>
</request>
</entry>
</Bundle>
In this example the bundle contains two Patient resources that are sent to server with a POST. For more information the structure of transaction/batch bundles,
please see the FHIR documentation at https://www.hl7.org/fhir/http.html and https://www.hl7.org/fhir/bundle.html.
In the table, each row corresponds to one resource that is created. To add the information for the request
element of the bundle,
this table has to be augmented with two columns named request.method
and request.url
, which contain the respective HTTP verb and URL for the resource.
If these columns are not added to the table, fhir_build_bundle()
still builds bundles from it, but those bundles will not be POSTable to a server. See examples.