Seiteninhalt:
In der TI greifen unterschiedliche Systeme auf FHIR-Schnittstellen zu oder stellen diese bereit. Viele Anforderungen gelten dabei für mehrere Systemtypen. Anforderungen an einen TI Client können beispielsweise sowohl für ein Primärsystem als auch für ein Frontend des Versicherten oder eine DiGA gelten.
TI Common definiert dafür gemeinsame Akteure als ActorDefinition-Instanzen. Obligations können diesen Akteuren zugeordnet und dadurch für verschiedene Systemtypen wiederverwendet werden.
Ein Akteur beschreibt die Rolle eines Systems innerhalb einer Interaktion. Er beschreibt weder ein konkretes Produkt noch eine Organisation oder eine Softwarearchitektur. Ein System kann mehrere Akteure implementieren. Ein System, das in einer Interaktion einen TI Service aufruft und in einer anderen Interaktion selbst eine Schnittstelle bereitstellt, kann beispielsweise sowohl TI Client als auch TI Service sein.
TI Common unterscheidet zunächst zwischen den folgenden grundlegenden Akteuren:
| TI Client |
Ein System, das in einem TI-gestützten Informationsaustausch als Client agiert. |
| TI Service |
Ein System, das Schnittstellen für einen TI-gestützten Informationsaustausch bereitstellt. |
Die Rollen TI Client und TI Service schließen sich nicht gegenseitig aus. Sie werden jeweils im Kontext der betrachteten Interaktion angewendet.
Ein spezialisierter Akteur verweist mit ActorDefinition.derivedFrom auf den allgemeineren Akteur, von dem er abgeleitet ist. Auf diese Weise entsteht eine Hierarchie wiederverwendbarer Akteure.
Die aktuell in TI Common definierte Hierarchie umfasst:
Ein abgeleiteter Akteur wird in JSON beispielsweise wie folgt definiert:
{
"resourceType" : "ActorDefinition",
"id" : "TIPrimarySystem",
"url" : "https://gematik.de/fhir/ti/ActorDefinition/TIPrimarySystem",
"name" : "TIPS",
"title" : "TI Primärsystem",
"status" : "active",
"type" : "system",
"derivedFrom" : [
"https://gematik.de/fhir/ti/ActorDefinition/TIClient"
]
}
Die Ableitung beschreibt eine fachliche Spezialisierung. Sie bedeutet nicht, dass der abgeleitete Akteur eine konkrete technische Komponente oder ein bestimmtes Produkt darstellt.
Obligations beschreiben, welche Verpflichtungen ein Akteur für ein FHIR-Profil oder für einzelne Elemente dieses Profils erfüllen muss. Sie können festlegen, dass im Zusammenhang mit dem Zugriff auf ein Element eine weitere Aktion auszuführen ist. Eine Obligation kann auch negativ formuliert sein und eine bestimmte Aktion ausdrücklich verbieten. So kann eine Obligation beispielsweise vorgeben, dass ein TI Client ein Element verarbeiten oder anzeigen muss, es beim Erzeugen einer Ressourceninstanz befüllen muss oder eine bestimmte Verarbeitung nicht durchführen darf.
Für die Anwendung von Obligations auf abgeleitete Akteure gilt:
Eine Obligation, die einem Akteur zugeordnet ist, gilt auch für alle Akteure, die direkt oder transitiv von diesem Akteur abgeleitet sind.
Eine Obligation für den TI Client gilt damit unter anderem auch für ein Primärsystem, ein FdV und eine DiGA. Eine Obligation für das TI Primärsystem gilt zusätzlich für alle davon abgeleiteten Primärsystemtypen wie PVS, ZPVS, KIS oder PPS. Ein abgeleiteter Akteur kann zusätzliche oder konkretere Obligations erhalten. Diese ergänzen die Obligations der übergeordneten Akteure. Eine Spezialisierung darf die Verpflichtungen eines übergeordneten Akteurs nicht abschwächen. Wenn mehrere anwendbare Obligations unterschiedlich streng sind, ist die strengere Verpflichtung zu erfüllen. Die technische Durchsetzung einer Obligation und der Umgang mit einer Verletzung sind nicht in TI Common festgelegt. Sie liegen in der Verantwortung des verarbeitenden Systems und richten sich nach der dort geltenden Security Policy sowie gegebenenfalls nach weiteren anwendungsspezifischen Festlegungen.
Die in der Obligation Extension verwendeten Codes stammen aus dem [Obligation Codes ValueSet]. Die Codes verbinden eine Verbindlichkeit wie SHALL, SHOULD oder MAY mit dem erwarteten Verhalten eines Akteurs. Beispiele sind SHALL:populate-if-known, SHALL:handle und MAY:display.
Die folgende Abbildung zeigt beispielhaft, wie unterschiedliche Obligations für ein Profilelement verschiedenen Akteuren zugeordnet werden können. Im Beispiel muss der TI Service Procedure.code befüllen, sofern der Wert bekannt ist, ein PVS muss das Element verarbeiten können und ein FdV darf den enthaltenen Wert anzeigen.
Akteure aus TI Common können in anderen FHIR Packages verwendet werden, wenn das TI-Common-Package als Abhängigkeit eingebunden ist.
Jeder Akteur wird durch eine ActorDefinition beschrieben und über die in ActorDefinition.url angegebene Canonical URL eindeutig identifiziert. Ein abgeleiteter Akteur verweist in ActorDefinition.derivedFrom auf die Canonical URL des übergeordneten Akteurs. Andere FHIR IGs können auf dieser Grundlage weitere, fachlich konkretere Akteure definieren.
Ein FHIR IG für den dokumentenbasierten Informationsaustausch kann beispielsweise den Akteur MHDDocumentConsumer definieren. Dieser beschreibt ein System, das auf
Grundlage von IHE MHD nach Dokumenten sucht und Dokumente abruft.
Da der MHDDocumentConsumer dafür Schnittstellen eines TI Service aufruft, wird er über ActorDefinition.derivedFrom vom Akteur TIClient abgeleitet. Damit gelten für den MHDDocumentConsumer auch alle allgemeinen Obligations des TIClient.
Ein Praxisverwaltungssystem, das als MHD Document Consumer agiert, besitzt damit zwei unterschiedliche Rollen:
| Dimension | Akteur |
|---|---|
| Systemrolle | TIPVS |
| Fachliche Rolle | MHDDocumentConsumer |
Um beide Rollen zusammenzuführen, kann beispielsweise ein Akteur MHDPVSDocumentConsumer definiert werden. Dessen ActorDefinition.derivedFrom verweist auf beide übergeordneten Akteure:
{
"resourceType": "ActorDefinition",
"id": "ExpActor",
"url": "https://gematik.de/fhir/example/ActorDefinition/ExpActor",
"name": "ExpActor",
"title": "Beispiel-Akteur",
"status": "active",
"type": "system",
"derivedFrom": [
"https://gematik.de/fhir/ti/ActorDefinition/TIPVS",
"https://gematik.de/fhir/mhd/ActorDefinition/MHDDocumentConsumer"
]
}
Für den MHDPVSDocumentConsumer gelten dadurch sowohl die allgemeinen Obligations von TIClient, TIPrimarySystem und TIPVS als auch die fachlichen Obligations des MHDDocumentConsumer.
Der Akteur TIService beschreibt allgemein ein System, das Schnittstellen oder Dienste in der TI bereitstellt. Konkrete fachliche Services können direkt von diesem Akteur abgeleitet werden.
Beispiele für solche Ableitungen sind:
Der EPAMedicationService ist ein spezialisierter Service für den digital gestützten Medikationsprozess (dgMP) in der ePA. Der WorkflowService ist ein weiteres Beispiel für einen spezialisierten TI Service.
Für eine Obligation sollte der allgemeinste Akteur gewählt werden, für den die Anforderung vollständig gilt:
Eine Zuordnung zu einem unnötig konkreten Akteur sollte vermieden werden, da andernfalls fachlich gleichartige Anforderungen mehrfach definiert werden müssten.