Seiteninhalt:
Jeder FHIR Data Service muss eingehende Daten konsistent untereinander und mit bestehenden Ressourceninstanzen verknüpfen. Die Aufgabe, die ggf. zu verknüpfenden Instanzen zu identifizieren und ein konsistentes Gesamtpaket zusammenzustellen, muss bei Verwendung der regulären FHIR RESTSful API durch die Clients (d.h. Primärsysteme) umgesetzt werden. Um den zahlreichen Primärsystemen die Implementierung der komplexen und fehleranfälligen Geschäftslogik zu ersparen, bieten die FHIR Data Services stattdessen FHIR Operations an, die jeweils eine spezifische Fachoperation umsetzen und anstelle der Primärsysteme die entsprechenden logischen Ressourcenverknüpfungen im FHIR Data Service vornehmen.
In der Architektur des FHIR Data Service sollte so wenig Geschäftslogik wie möglich im Primärsystem verankert sein. Stattdessen sollte die zentrale Verarbeitung im Aktensystem erfolgen. Dies ermöglicht eine konsistente, standardisierte und interoperable Verarbeitung der Daten und reduziert die Komplexität der Primärsysteme.
Schreibvorgänge sollten bevorzugt über die Operation API erfolgen. Dabei gilt:
Der FHIR Data Service übernimmt die Kontrolle über die Referenzierung von Ressourcen und stellt sicher, dass Client-Systeme keine direkten Referenzen setzen:
In einem FHIR Data Service können Operationen von verschiedenen Client-Systemen gleichzeitig ausgelöst werden. Dies kann zu Problemen führen, wenn Client-Systeme gleichzeitig lesend und insbesondere schreibend auf dieselben Informationen im FHIR Data Service zugreifen. Daher werden in den Definitionen der Operationen, bei denen konkurrierende Lese- und Schreibzugriffe voneinander isoliert werden müssen, Bereiche mit sogenannten “Transaktionen” definiert. Derart gekennzeichnete Bereiche müssen dem aus dem Datenbankprinzip bekannten ACID-Prinzip (“atomicity, consistency, isolation and durability”) genügen, d.h. die in diesem Bereich ausgeführten Zugriffe müssen zusammen genommen
Von besonderer Bedeutung ist hierbei das Prinzip der “isolierten” Ausführung, nach dem Lese- oder Schreibzugriffe innerhalb eines Transaktionsblocks nicht durch Zugriffe einer zweiten, gleichzeitig ablaufenden Transaktion beeinflusst werden dürfen. Im FHIR Data Service müssen transaktional gekennzeichnete Bereiche isoliert im Sinne von “serialisierbar” (“serialized”) behandelt werden. Das bedeutet, dass gleichzeitig ablaufende Operationen das Ergebnis der jeweils anderen Operation nicht beeinflussen dürfen, sondern beide so ausgeführt werden müssen, dass das Ergebnis identisch ist mit dem Ergebnis einer getrennten, nacheinander ablaufenden Ausführung. Auf diese Weise können typische Probleme wie “Dirty Reads” vermieden werden.
Auch bei der Verwendung von Transaktionen kann es vorkommen, dass zwei Client-Systeme dieselbe Ressourceninstanz lesen (z.B. über die reguläre FHIR Query API), um anschließend die Werte darin über eine Operation zu aktualisieren. Auch wenn beide Aktualisierungsoperationen nacheinander ausgeführt werden, ist nur das Ergebnis der als zweites ausgeführten Transaktion dauerhaft in dem FHIR Data Service sichtbar. Das Client-System, dessen Transaktion zuerst ausgeführt wurde, erfährt nicht, dass die von ihm gewünschte Aktualisierung nicht in dem FHIR Data Service persistiert wurde. Aus diesem Grund verlangen einige Operationen des FHIR Data Service, die FHIR-Ressourceninstanzen schreiben, dass immer die aktuelle Versionsnummer der zu aktualisierenden Ressourceninstanz übergeben wird. Wenn nun zwei Transaktionen die gleiche Version einer Ressourceninstanz aktualisieren wollen, wird die als erstes ausgeführte Transaktion erfolgreich sein (da die aktuelle Versionsnummer im FHIR Data Service mit der zu aktualisierenden Versionsnummer aus der Transaktion identisch ist), aber die als zweites ausgeführte Transaktion zurückgewiesen, da sich die Versionsnummer im FHIR Data Service in der Zwischenzeit erhöht hat. Letztere Transaktion würde vom FHIR Data Service abgelehnt und mit einem Fehler beantwortet. Das entsprechende Client-System kann dann versuchen, die aktuelle Version der Ressourceninstanz erneut zu ermitteln, um die Transaktion mit der aktualisierten Versionsnummer erneut zu starten.
Daraus ergeben sich die folgenden Anforderungen: