NOTE: TODO discuss how provenace could be added after (i.e. not contained), but not in a transaction. If provence needed to be linked to a versioned resource (seems reasonable), this isn't supported https://build.fhir.org/bundle.html#references. Also see https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Provenance.20in.20a.20bundle. Using an etag would work. If the provenance was created after and took the etag of the resource from the response, which should come back for each resource in transaction, the provenance.target could then be set to a versioned url (assuming this was required). Benefits of this would be ability to expand the scope of the provenace. If it really doesn't have a lifetime outside of the resource, contained is probably tidier but definetly less flexible. More discussion here ttps://chat.fhir.org/#narrow/stream/179166-implementers/topic/Transaction.20Bundle.20with.20Provenance/near/402326516. @@ -51,7 +51,7 @@ The master Flag and condition Flag (and associated Condition) resources are incl The second example given here simply adds conditions to the previous transaction resource to demonstrate the ability to add new conditions to the same data structure and reply in an idempotent way. The request entry in the transaction Bundle for the second condition uses the uuid from the fullUrl on the Bundle entry to use in the URL for the PUT method. The first uses the patient uuid as a search parameter for the PUT. A uuid would be the preferred method to construct the uuid for the fullUrl in the Bundle entry, so this should be a reasonable example. This example is just to demonstrate ReSTful capabilities of the FHIR spec.
-[Example Transaction: Additional condition and flag added to previous Transaction](Bundle-add-condition-transaction-example-2.html). +[Example Transaction: Additional condition and flag added to previous Transaction](Bundle-0001-add-condition-transaction-example.html).TODO: maybe cover other ways of doing this, all POST's, if-match, X-provenance, batch tranaction etc... diff --git a/input/pagecontent/server-example-add-ra-record.md b/input/pagecontent/server-example-add-ra-record.md index f534f67..1f5b7bf 100644 --- a/input/pagecontent/server-example-add-ra-record.md +++ b/input/pagecontent/server-example-add-ra-record.md @@ -38,8 +38,8 @@ TODO #### Example 2 -The first [example transaction](Bundle-add-condition-transaction-example-1.html) adds an RA record consisting of a Consent resource from the patient, a master Flag resource (is this really needed?), a Condition resource and an associated condition Flag resource using a transaction Bundle, which provides atomicity as well as more network efficent call. Each Flag resource has a Provenance resource embedded in it. (TODO maybe a futher discussion section somewhere on options for provenance, i.e. linking to versions, _history and transaction considerations, options to use etag or X-provenance). +The first [example transaction](Bundle-0001-add-condition-transaction-example.html) adds an RA record consisting of a Consent resource from the patient, a master Flag resource (is this really needed?), a Condition resource and an associated condition Flag resource using a transaction Bundle, which provides atomicity as well as more network efficent call. Each Flag resource has a Provenance resource embedded in it. (TODO maybe a futher discussion section somewhere on options for provenance, i.e. linking to versions, _history and transaction considerations, options to use etag or X-provenance). -The second [example transaction](Bundle-add-condition-transaction-example-1.html) simply modifies the first transaction by adding additional resources for another Condition and adjustment (Flag). The transactions are using PUT's and as FHIR does defined (upsert)[https://hl7.org/fhir/http.html#upsert] as an option, and the HAPI Starter Server has implemented this, this example has been constructed to demostrate this. +The second [example transaction](Bundle-0002-add-condition-transaction-example.html) simply modifies the first transaction by adding additional resources for another Condition and adjustment (Flag). The transactions are using PUT's and as FHIR does defined (upsert)[https://hl7.org/fhir/http.html#upsert] as an option, and the HAPI Starter Server has implemented this, this example has been constructed to demostrate this. Details of querying the resulting data from these transaction is given in the [Retrieve RA Record](server-example-add-ra-record.html) server example. \ No newline at end of file diff --git a/input/pagecontent/server-example-retrieve-ra-record.md b/input/pagecontent/server-example-retrieve-ra-record.md index 06f6ed2..fe24b7d 100644 --- a/input/pagecontent/server-example-retrieve-ra-record.md +++ b/input/pagecontent/server-example-retrieve-ra-record.md @@ -42,9 +42,9 @@ Based on the example transaction Bundles given in the use case [Add RA Record](a This query will return the Patient resource using the patients NHS number (TODO will be profiled to check for this, reference this later). The assocaited resources that make up the RA are also returned, which are all using default Patient SearchParameters define in the base specification for each resource. -For the [first transaction example](Bundle-add-condition-transaction-example-1.html), this is the [output of the query](Bundle-QUERY-OUTPUT--add-condition-transaction-example-1.html). +For the [first transaction example](Bundle-0001-add-condition-transaction-example.html), this is the [output of the query](Bundle-QUERY-OUTPUT--0001-add-condition-transaction-example.1.html). -For the [second transaction example](Bundle-add-condition-transaction-example-2.html), where a Condition and adjustment (Flag) is added, this is the [output of the query](Bundle-QUERY-OUTPUT--add-condition-transaction-example-2.html). +For the [second transaction example](Bundle-0002-add-condition-transaction-example.html), where a Condition and adjustment (Flag) is added, this is the [output of the query](Bundle-QUERY-OUTPUT--0002-add-condition-transaction-example.2.html). See the [Data Model](data-model.html) for details on the relationships between the resources.