0.1.0 - ci-build Switzerland flag

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

Implementation

Technische Implementation

Die in diesem IG beschriebenen Consents in KISIM werden gemäss den Resource Profiles als R5 FHIR Consent im FHIR Repository gespeichert.

Um Konflikte wie Duplikate und Lost Updates zu vermeiden, müssen client-seitig die Grundsätze zur Bewahrung der Transactional Integrity beachtet werden. Dazu werden version aware updates und conditional updates verwendet.

Grundsätze der transaktionellen Integration

Auszug aus der 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)

Wenn ein Client diesem Schema folgt, bleiben Informationen aus anderen Systemen, die sie nicht verstehen, auch durch das Update erhalten.

Voraussetzungen

Die zu referenzierenden Ressourcen

  • Patient
  • Organization
  • HealthcareService
  • RelatedPerson

müssen im FHIR Repository bereits existieren. Diese werden von der CISTEC AG erstellt.

Allgemeines Schema

Das Schema soll aufzeigen, nach welchem Vorgehen die Consent Ressourcen erstellt und gespeichert werden sollen.
Die Schritte 1 bis 3 werden in den weiteren Abschnitten genauer erklärt.

Ablauf Clientverhalten

Um herauszufinden, ob ein bestimmter Consent bereits existiert oder nicht und wenn ja, um dessen Version/ETag zu lesen, soll ein GET Request nach folgendem Schema gemacht werden:

GET [base]/Consent?<search parameters>

Wenn der entsprechende Consent existiert, muss dessen ID und der ETag(Version ID) zwischengespeichert werden für Schritt (3).

Search Parameter für die einzelnen Consents können in der Search Parameters Page nachgelesen werden.

(2) Conditional update

Ein conditional update soll nur dann verwendet werden, wenn beim lesen des Consents keine Ressource gefunden wird, also noch keine existiert.

PUT [base]/Consent?<search parameters>

Search Parameter für die einzelnen Consents können in der Search Parameters Page nachgelesen werden.

Outcome:

  • 201 (Created) => Consent wurde neu erzeugt, Ende
  • 200 (OK) => Consent hat bereits existiert, wurde geändert

(3) Version aware update

Wenn bereits eine Consent Ressource existiert, wird ein version aware update mit zuvor gelesener ID + ETag verwendet.
Die Änderungen werden in der gelesenen Ressource vorgenommen.

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

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

Outcome:

  • 200 (OK) => Consent wurde geändert, Ende
  • 409 (Conflict) oder 412 (Precondition Failed) => weak locking, anderer Client war vermutlich schneller. Nochmal bei Schritt (1) starten.

Alle Versionen des Consents mit der entsprechenden ID werden angezeigt.

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