Implementation Guide
ePA Common
Version 1.0.5-ballot.1 - draft

Operation API: Allgemeine Anforderungen

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.

Zentrale Geschäftslogik vor dezentraler Geschäftslogik

In der Architektur des ePA-Systems 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 per Operation API

Schreibvorgänge sollten bevorzugt über die Operation API erfolgen. Dabei gilt:

  • Dedizierte Geschäftslogik für Schreiben wenn möglich auf Instance API mit anwendungsspezifischen Constraints
  • Profilierung von FHIR R4 Parameter für Prüfung der Profilkonformität im Datenraum

Exklusives Erzeugen von Referenzen durch den FHIR Data Service

Der FHIR Data Service übernimmt die Kontrolle über die Referenzierung von Ressourcen und stellt sicher, dass Client-Systeme keine direkten Referenzen setzen:

  • Alle von Client-Systemen übergebenen Ressourcen werden als Data Transfer Objects betrachtet; intern werden neue Ressourcen erstellt und serverseitig verknüpft
  • Verwerfen von Literal References aus Client-Anfragen