Versioning

Supporting versions allows for related systems to track the correct version of information, and to keep the integrity of clinical records. Kodjin provides versioning support and allows users to populate and track versionId , use vread and _history operations, perform version aware updates.

Create

Whenever a new resource is created, Kodjin generates a version ID for it and returns it in the ETag header. The server also generates a Last-Modified header as well as a link to the history record in the Location header: Location: [base]/[type]/[id]/_history/[vid] Example:

https://demo.kodjin.comfhir/Patient/588ce81e-27fb-490c-8c50-e58fb899458b/_history/1

Read

_history operation can be used to retrieve the history of either a particular resource, all resources of a given type, or all resources supported by the system, e.g. https://demo.kodjin.comfhir/Patient/588ce81e-27fb-490c-8c50-e58fb899458b/_history

Update

Whenever a resource is updated, Kodjin generates a new version ID and returns it in the ETag header. If the request body includes a meta, Kodjin ignores the provided versionId and lastUpdated values. If the resource is created (Create as Update), the server will return a Location header as it would for a regular create operation. See more about Update here.

If-Match header

Versioning also helps to manage resource contention. You can use the If-Match header to prevent Lost Updates , where two clients update the same resource, and the second overwrites the updates of the first. Submit the request with an If-Match header that quotes the ETag from the server:

PUT /Patient/347 HTTP/1.1
If-Match: W/"23"

If the version ID given in the If-Match header does not match, Kodjin will return a 412 Precondition Failed status code instead of updating the resource.

Delete

The delete interaction does not remove a resource's version history. Though you will get 410 Gone status code accessing the deleted resource by ID, you can still perform _history or vread operations.
Read more about delete here.