0.1.1 - ci-build CH

KISIMConsent - Local Development build (v0.1.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Technical Implementation

The consents in KISIM described in this IG are saved as R5 FHIR Consents in the FHIR repository in accordance with the Resource Profiles.

To avoid conflicts such as duplicates and lost updates, the principles for preserving transactional integrity must be followed on the client side. For this purpose, version aware updates and conditional updates are used.

Principles of transactional integrity

Extract from the FHIR Specification:

  • The server provides a read interaction for any resource it accepts update interactions on
  • Before updating, the client reads the latest version of the resource
  • The client applies the changes it wants to the resource, leaving other information intact (note the extension related rules around this)
  • The client writes the result back as an update interaction, and is able to handle a 409 or 412 response (usually by trying again)

If clients follow this pattern, then information from other systems that they do not understand will be maintained through the update.

Notes:
If a client receives a copy of the resource in the response body of a create, update or patch, it SHOULD use the returned content as the basis for subsequent update or patch requests.

Prerequisites

The resources to be referenced

  • Patient
  • Organization
  • HealthcareService
  • RelatedPerson

must already exist in the FHIR repository. These are created by CISTEC AG.

General schema

The schema is intended to show the procedure for creating and saving consent resources.
Steps 1 to 3 are explained in more detail in the following sections.

Client behavior process

To find out whether a certain Consent already exists or not and if so, to read its version/ETag, a GET request should be performed according to the following scheme:

GET [base]/Consent?<search query>

If the corresponding Consent exists, its ID and the ETag(Version ID) must be cached for step (3).

Search Queries for the individual consents can be found in the Search Queries Page.

Note:
The FHIR Store has an internal cache for queries. Query results will be cached for 60 seconds. This can be seen in the X-Cache header if it's a cached result.
Then the response contains something like: "X-Cache-Header: HIT from..."
If for some reason no cached results are to be displayed, this can be avoided by adding the request header:

Cache-Control = no-cache

(2) Conditional update

A conditional update should only be performed if no resource is found when reading the consent, i.e. none exists yet.

PUT [base]/Consent?<search query>

Search Queries for the individual consents can be found in the Search Queries Page.

Outcome:

  • 201 (Created) => Consent was newly created, end
  • 200 (OK) => Consent already existed, has been altered

(3) Version aware update

If a Consent resource already exists, a version aware update with previously read ID + ETag is used.
The changes are made to the read resource.

PUT [base]/Consent/<Consent ID> HTTP/1.1

Headers: If-Match = W/"<ETag>"

Outcome:

  • 200 (OK) => Consent has been altered, end
  • 409 (Conflict) or 412 (Precondition Failed) => weak locking, other client was probably faster. Start again at step (1).

All versions of the consent with the corresponding ID are displayed.

GET [base]/Consent/<Consent ID>_history