Die Vertragspartnersoftware-Schnittstelle stellt diverse Service-Endpoints zur Verfügung.
Hinweis bzgl. der Verwendung bestimmter Begriffe:
Es erfolgte in den Fehlermeldungen und auf der GUI des e-card-Systems (eCS) ein Wording-Umstieg für folgende Begriffe:
Wichtig: Anzeigetexte aus Regelwerksabfragen (z.B. Behandlungsfälle (KSE), Rückdatierungsgründe (AUM),... ) sind unverändert anzuzeigen!
Es wird zwecks Vereinheitlichung und leichterer Bedienbarkeit empfohlen dieselben Begriffe in der Vertragspartnersoftware (VPSW) zu verwenden.
In den Beschreibungen der Javadoc werden, um die Verständlichkeit und die Lesbarkeit zu erleichtern, im Text jeweils die männlichen Formulierungen (Patient, Vertragspartner, Arzt, ...) verwendet.
Die Formulierungen gelten gleichermaßen für Frauen und Männer.
SV-Träger Sozialversicherungsträger |
KV-Träger (bevorzugt) Krankenversicherungsträger |
Ordinationskarte | |
Wichtig: Anzeigetexte aus Regelwerksabfragen (z.B. Behandlungsfälle (KSE), Rückdatierungsgründe (AUM),... ) sind unverändert anzuzeigen!
Es wird zwecks Vereinheitlichung und leichterer Bedienbarkeit empfohlen dieselben Begriffe in der Vertragspartnersoftware (VPSW) zu verwenden.
In den Beschreibungen der Javadoc werden, um die Verständlichkeit und die Lesbarkeit zu erleichtern, im Text jeweils die männlichen Formulierungen (Patient, Vertragspartner, Arzt, ...) verwendet.
Die Formulierungen gelten gleichermaßen für Frauen und Männer.
Einsatz der Vertragspartnersoftware:
Ausgewählte Funktionen des e-card-Systems werden für die Vertragspartnersoftware über ein SOAP- bzw. REST-Interface
zur Verfügung gestellt.
Die zur Verfügung gestellten Funktionen sowie Ein- und Ausgangsparameter der SOAP-Services werden jeweils durch WSDL-Files
spezifiziert.
Überblick über die Komponenten für die Vertragspartnersoftware
Überblick über die Komponenten für die Vertragspartnersoftware
Das e-card System stellt mehrere Services (SOAP / REST) für die Verwendung zur Verfügung.
Mit dem Projekt GINAaaS erfolgt eine Schrittweise Umstellung der Services auf reine Server Projekte.
D.h. es erfolgt eine Ablöse der GINA. Bestehende Services die bereits umgestellt wurden, sind sowohl über die GINA als auch über den Server verfügbar.
Die Abfrage der URLs zu den einzelnen Services erfolgt mittels des ServiceManagers.
Bei Verwendung des Servicemanagers über die GINA (<gina-adresse>) werden die auf der GINA bzw. dem GINA-Proxy verfügbaren Services retourniert.
Weitere Informationen über die Nutzung des GINA Proxys erhalten Sie auf Anfrage beim Partnersupport.
Für die Abfrage der zentralen Services ist der Servicemanager unter folgender URL abrufbar:
Hinweis: Zusätzlich zu den verfügbaren SOAP Services werden auch Informationen über die verfügbaren REST Services retourniert.
Für die Produktion gilt: Der "direkte" Aufruf über den Server ist aktuell nur bei Verwendung des GINA Proxys möglich.
In der VPSWH-Umgebung erfolgt ein direkter Zugriff auf die zentralisierten Services.
Man unterscheidet folgende vier Basis-Services:
Mit dem Projekt GINAaaS erfolgt eine Schrittweise Umstellung der Services auf reine Server Projekte.
D.h. es erfolgt eine Ablöse der GINA. Bestehende Services die bereits umgestellt wurden, sind sowohl über die GINA als auch über den Server verfügbar.
Die Abfrage der URLs zu den einzelnen Services erfolgt mittels des ServiceManagers.
Bei Verwendung des Servicemanagers über die GINA (<gina-adresse>) werden die auf der GINA bzw. dem GINA-Proxy verfügbaren Services retourniert.
Weitere Informationen über die Nutzung des GINA Proxys erhalten Sie auf Anfrage beim Partnersupport.
Für die Abfrage der zentralen Services ist der Servicemanager unter folgender URL abrufbar:
- Produktion:
- https://services.ecard.sozialversicherung.at/servicemanager/1
- Vertragspartnersoftware-Hersteller Umgebung:
- https://services-a.ecard-test.sozialversicherung.at/servicemanager/1
Hinweis: Zusätzlich zu den verfügbaren SOAP Services werden auch Informationen über die verfügbaren REST Services retourniert.
Für die Produktion gilt: Der "direkte" Aufruf über den Server ist aktuell nur bei Verwendung des GINA Proxys möglich.
In der VPSWH-Umgebung erfolgt ein direkter Zugriff auf die zentralisierten Services.
Man unterscheidet folgende vier Basis-Services:
- BASE
- AUTH
- FDAS
- GINA
BASE:
Funktionalität für die Serviceverfügbarkeitsabfrage, der Ordinationsübersiedlung, dem Message-, dem Vertrags- und dem Berechtigungshandling.
AUTH:
Funktionalität um einen Dialog aufzubauen und zu beenden.
FDAS:
Abfrage-Funktionalität für dynamische Werte aus dem Regelwerk.
GINA:
Funktionalität zur Verwaltung der GINA und der Kartenleser.
Hinweis: Mit Abschluss des Projektes GINAaaS (wenn alle Services auf reine Server-Sevices umgestellt sind), wird dieses Service nicht mehr benötigt werden (da dann die GINA nicht mehr benötigt wird). Genauere Informationen wie auf die Daten danach zugegriffen werden kann, werden zeitgerecht bereitgestellt werden.
Das GINA Service bietet die Möglichkeit der Kartenleserverwaltung (Abfrage der Kartenleser).
Der Zugriff auf den Kartenleser wird nicht über das GINA Service zur Verfügung gestellt (und auch nicht über ein anderes SOAP Service).
Für die Kommunikation mit dem LANCCR ist folgendes REST Service zu verwenden: Swagger Doku LANCCR.
Die Schnittstelle dient zum Auslesen von Kartendaten, dem Erstellen von Signaturtoken, der Kartenleserüerwachung (Ablöse von "getReaderStatusEvent()"), usw.
Die Kommunikation per REST erfolgt aktuell über die GINA. Mit einer späteren Release wird dies umgestellt, sodass die Kommunikation direkt mit dem Kartenleser erfolgt (neue Kartenlesergeneration - GINO).
Hinweis: Durch die spätere Umstellung der Kommuniktation direkt mit dem Kartenleser ändert sich nur die Aufruf-URL (Host).
Folgende Funktionalitäten sind durch die VPSW selbst mittels der angebotenen REST Schnittstelle selbst zu verwalten:
Funktionalität für die Serviceverfügbarkeitsabfrage, der Ordinationsübersiedlung, dem Message-, dem Vertrags- und dem Berechtigungshandling.
Funktionalität um einen Dialog aufzubauen und zu beenden.
Abfrage-Funktionalität für dynamische Werte aus dem Regelwerk.
Funktionalität zur Verwaltung der GINA und der Kartenleser.
Hinweis: Mit Abschluss des Projektes GINAaaS (wenn alle Services auf reine Server-Sevices umgestellt sind), wird dieses Service nicht mehr benötigt werden (da dann die GINA nicht mehr benötigt wird). Genauere Informationen wie auf die Daten danach zugegriffen werden kann, werden zeitgerecht bereitgestellt werden.
Das GINA Service bietet die Möglichkeit der Kartenleserverwaltung (Abfrage der Kartenleser).
Der Zugriff auf den Kartenleser wird nicht über das GINA Service zur Verfügung gestellt (und auch nicht über ein anderes SOAP Service).
Für die Kommunikation mit dem LANCCR ist folgendes REST Service zu verwenden: Swagger Doku LANCCR.
Die Schnittstelle dient zum Auslesen von Kartendaten, dem Erstellen von Signaturtoken, der Kartenleserüerwachung (Ablöse von "getReaderStatusEvent()"), usw.
Die Kommunikation per REST erfolgt aktuell über die GINA. Mit einer späteren Release wird dies umgestellt, sodass die Kommunikation direkt mit dem Kartenleser erfolgt (neue Kartenlesergeneration - GINO).
Hinweis: Durch die spätere Umstellung der Kommuniktation direkt mit dem Kartenleser ändert sich nur die Aufruf-URL (Host).
Folgende Funktionalitäten sind durch die VPSW selbst mittels der angebotenen REST Schnittstelle selbst zu verwalten:
- Karten-Handling (Lesen, PIN/PUK)
- Kartenleserüberwachung
Voraussetzungen für die Vertragspartnersoftware:
Voraussetzung für die clientseitige SOAP-Unterstützung ist ein TCP/IP-Stack sowie eine Bibliothek für
SSL-Verschlüsselung.
Die Vertragspartnersoftware muss einen SOAP-Client verwenden, der mittels HTTPS-Protokoll auf einer definierten URL synchrone Funktionsaufrufe im SOAP-Format durchführt.
Der zu verwendende Port ist 443. Die zu verwendende URL wird vom Service-Manager zurückgeliefert.
Das Ergebnis wird über einen HTTPS-Response zurückgeliefert.
Die Verarbeitung einlangender Requests innerhalb eines Dialoges erfolgt im e-card-System serialisiert.
D.h. der Request wird verarbeitet und eine entsprechende Response retourniert. Erst nach Retournierung der Response erfolgt die Verarbeitung eines weiteren Requests. Wird ein Request vor Erhalt der Response des vorangegangenen Requests geschickt, muss dieser warten bis der vorherige Funktionsaufruf vollständig abgearbeitet wurde und eine entsprechende Response geliefert wurde. Bei vielen "gleichzeitigen" Requests innerhalb desselben Dialogs (mit derselben DialogID) besteht daher die Gefahr von langen Wartezeiten bzw. von Timeouts.
Zusätzlich besteht von Seiten des e-card Systems die Möglichkeit die Anzahl gleichzeitiger Requests von einem Vertragspartner zu begrenzen wenn festgestellt wird, das zuviele Request auf einmal übermittelt werden. In diesem Fall wird die Fehlermeldung ZS-10041 (Fehlerkonstante ServiceException.INTERNAL_ERROR) retourniert!
Als SOAP Programmiermodell wird RPC verwendet. Die SOAP-Nachrichten werden im Format Document/Literal (wrapped) übertragen. Asynchrone Benachrichtigungen vom Ordinationsclient zur Vertragspartnersoftware werden nicht unterstützt.
In den WSDL-Files werden eigens definierte Datentypen verwendet (Complex Types), die sich aus einfachen Datentypen (int, String. ..) zusammensetzen. Diese Datentypen können als Rückgabewerte der aufgerufenen Funktionen, als Parameter bzw. in Form von Fehlermeldungen (Exceptions) auftreten.
Abhängig vom verwendeten SOAP-Toolkit auf der Clientseite, kann ein so genanntes Type-Mapping notwendig sein. Dazu müssen die WSDL-Datentypen mit den entsprechenden Implementierungsklassen der Zielsprache verknüpft werden.
Request-Timeouts:
Um das Hängenbleiben der Vertragspartnersoftware aufgrund von Fehlersituationen bei der Durchführung von Funktionen zu verhindern, sollten die Funktionsaufrufe mittels Timeout-Steuerung überwacht werden. Die angebotenen Funktionen werden bezüglich ihrer Laufzeit in drei Gruppen unterteilt:
In der nachfolgenden Tabelle sind die empfohlenen Timeout-Werte je Laufzeitgruppe beschrieben.
In der technischen Schnittstellenbeschreibung (Javadoc) ist für angebotene Funktion die Zugehörigkeit zur entsprechenden Laufzeitgruppe und damit der empfohlene Timeout-Wert beschrieben.
Besteht aus Implementierungsgründen nicht die Möglichkeit die Timeout-Steuerung pro Funktionsaufruf zu parametrieren so ist allgemein der Timeout-Wert der Laufzeitgruppe Lang zu setzen.
Für die Kommunikation mit dem Kartenleser über REST ist ein entsprechender REST-Client notwendig.
Die Vertragspartnersoftware muss einen SOAP-Client verwenden, der mittels HTTPS-Protokoll auf einer definierten URL synchrone Funktionsaufrufe im SOAP-Format durchführt.
Der zu verwendende Port ist 443. Die zu verwendende URL wird vom Service-Manager zurückgeliefert.
Das Ergebnis wird über einen HTTPS-Response zurückgeliefert.
Die Verarbeitung einlangender Requests innerhalb eines Dialoges erfolgt im e-card-System serialisiert.
D.h. der Request wird verarbeitet und eine entsprechende Response retourniert. Erst nach Retournierung der Response erfolgt die Verarbeitung eines weiteren Requests. Wird ein Request vor Erhalt der Response des vorangegangenen Requests geschickt, muss dieser warten bis der vorherige Funktionsaufruf vollständig abgearbeitet wurde und eine entsprechende Response geliefert wurde. Bei vielen "gleichzeitigen" Requests innerhalb desselben Dialogs (mit derselben DialogID) besteht daher die Gefahr von langen Wartezeiten bzw. von Timeouts.
Zusätzlich besteht von Seiten des e-card Systems die Möglichkeit die Anzahl gleichzeitiger Requests von einem Vertragspartner zu begrenzen wenn festgestellt wird, das zuviele Request auf einmal übermittelt werden. In diesem Fall wird die Fehlermeldung ZS-10041 (Fehlerkonstante ServiceException.INTERNAL_ERROR) retourniert!
Als SOAP Programmiermodell wird RPC verwendet. Die SOAP-Nachrichten werden im Format Document/Literal (wrapped) übertragen. Asynchrone Benachrichtigungen vom Ordinationsclient zur Vertragspartnersoftware werden nicht unterstützt.
In den WSDL-Files werden eigens definierte Datentypen verwendet (Complex Types), die sich aus einfachen Datentypen (int, String. ..) zusammensetzen. Diese Datentypen können als Rückgabewerte der aufgerufenen Funktionen, als Parameter bzw. in Form von Fehlermeldungen (Exceptions) auftreten.
Abhängig vom verwendeten SOAP-Toolkit auf der Clientseite, kann ein so genanntes Type-Mapping notwendig sein. Dazu müssen die WSDL-Datentypen mit den entsprechenden Implementierungsklassen der Zielsprache verknüpft werden.
Request-Timeouts:
Um das Hängenbleiben der Vertragspartnersoftware aufgrund von Fehlersituationen bei der Durchführung von Funktionen zu verhindern, sollten die Funktionsaufrufe mittels Timeout-Steuerung überwacht werden. Die angebotenen Funktionen werden bezüglich ihrer Laufzeit in drei Gruppen unterteilt:
In der nachfolgenden Tabelle sind die empfohlenen Timeout-Werte je Laufzeitgruppe beschrieben.
| Laufzeitgruppe | EmpfohlerTimeout-Wert |
|---|---|
In der technischen Schnittstellenbeschreibung (Javadoc) ist für angebotene Funktion die Zugehörigkeit zur entsprechenden Laufzeitgruppe und damit der empfohlene Timeout-Wert beschrieben.
Besteht aus Implementierungsgründen nicht die Möglichkeit die Timeout-Steuerung pro Funktionsaufruf zu parametrieren so ist allgemein der Timeout-Wert der Laufzeitgruppe Lang zu setzen.
Für die Kommunikation mit dem Kartenleser über REST ist ein entsprechender REST-Client notwendig.
Request Wiederholung (Replay)
Erfolgt keiner Rückmeldung an die VPSWH, kann es passieren, dass dem Benutzer nicht bekannt
ist wie weit der Request gekommen ist.
Aus diesem Grund gibt es die Möglichkeit denselben Request nochmals zu senden.
Ist der erste Versuch bereits am Server verarbeitet worden, wird einfach die Antwort zurückgeschickt, die eigentlich bereits für den ersten Request zurückkommen hätte sollen, ohne den Request ein zweites Mal zu verarbeiten.
Um dabei den Request eindeutig identifizieren zu können, muss beide Male dieselbe TransactionId im Message-Header des Request gesetzt sein.
TransaktionsId: <soap:TransactionId>Platzhalter</soap:TransactionId>
Hinweis: In der technischen Schnittstellenbeschreibung (Javadoc) ist bei Funktionen, welche die Replay-Funktionalität implementieren, der Hinweis "Replayability: [Ja|Nein]." dokumentiert.
Die TransactionId ist von der Vertragspartnersoftware zu generieren und hat folgende Anforderungen:
Bis zur verpflichtenden Angabe gelten folgende Bedingungen:
Aus diesem Grund gibt es die Möglichkeit denselben Request nochmals zu senden.
Ist der erste Versuch bereits am Server verarbeitet worden, wird einfach die Antwort zurückgeschickt, die eigentlich bereits für den ersten Request zurückkommen hätte sollen, ohne den Request ein zweites Mal zu verarbeiten.
Um dabei den Request eindeutig identifizieren zu können, muss beide Male dieselbe TransactionId im Message-Header des Request gesetzt sein.
TransaktionsId: <soap:TransactionId>Platzhalter</soap:TransactionId>
Hinweis: In der technischen Schnittstellenbeschreibung (Javadoc) ist bei Funktionen, welche die Replay-Funktionalität implementieren, der Hinweis "Replayability: [Ja|Nein]." dokumentiert.
Die TransactionId ist von der Vertragspartnersoftware zu generieren und hat folgende Anforderungen:
- Für jeden neuen Request muss eine eigene TransactionId erzeugt werden
- Darf weder mit null noch mit einem Leerstring versorgt werden
- Darf nicht länger als 100 Zeichen sein
- Muss eindeutig sein (GUID - Globally-Unique-Identifier, siehe auch Wikipedia - GUID, z.B. per java.util.UUID)
- Bei mehr als einer Vertragspartnersoftware, muss jede Software ihre eigenen TransactionIds verwenden
- Bei der Wiederholung eines Request, muss die TransactionId bei jedem Versuch dieselbe sein
Bis zur verpflichtenden Angabe gelten folgende Bedingungen:
- Die TransactionId ist optional anzugeben - eine Nichtangabe führt nicht zum Fehler.
- Die Angabe der TransactionId kann mittels "ForceConfirmation" im SOAP Header getestet werden.
Wird ForceConfirmation im Header angegeben, wird die angegebene TransactionId im Response retourniert.
Beispiel Request:
<soapenv:Header>Beispiel Response:
<soap:ForceConfirmation/>
<soap:TransactionId>1234567</soap:TransactionId>
</soapenv:Header>
<soap:Confirmation xmlns:soap="http://soap.base.client.chipkarte.at">Hinweis: Wird der Request Failover-fähig erzeugt, ist bereits jetzt im Response die Confirmation der TransaktionsId enthalten!
<TransactionId>1234567</TransactionId>
</soap:Confirmation>
- Wird die TransactionId nicht angegeben, wird die Exception DialogExceptionConstants.INVALID_TRANSACTION_ID retourniert.
- Die Prüfung mittels "ForceConfirmation"-Header ist nicht mehr möglich.
- Die Retournierung der TransactionId als Confirmation im Response wird nicht mehr unterstützt.
Patientendaten:
Sofern für einen Patienten im e-card-System mehr als eine Schreibweise des Namens vorhanden ist, werden alle Namensdaten retourniert.
Ist nur eine Schreibweise vorhanden, werden nur Namensfelder ohne "Druck-Prefix" befüllt. Ist zusätzlich noch eine weitere Schreibweise vorhanden, werden zusätzlich die "Druck"-Felder befüllt.
Bezüglich der einzelnen Erweiterungen in den Personendatenobjekten ist die Javadoc-Beschreibung der einzelnen Services zu beachten.
Wichtiger Hinweis:
Nicht jedes Service bietet aufgrund fachlicher oder technischer Gegebenheiten (bei jeder Funktion) eine doppelte Namenslieferung an.
Beispiele:
Bei Abfragen der Ansprüche in die Vergangenheit mittels VDAS werden Daten aus einem Drittsystem geliefert – ohne Doppellieferung der Namensdaten bei abgeleiteten Ansprüchen.
Ist nur eine Schreibweise vorhanden, werden nur Namensfelder ohne "Druck-Prefix" befüllt. Ist zusätzlich noch eine weitere Schreibweise vorhanden, werden zusätzlich die "Druck"-Felder befüllt.
Bezüglich der einzelnen Erweiterungen in den Personendatenobjekten ist die Javadoc-Beschreibung der einzelnen Services zu beachten.
Wichtiger Hinweis:
Nicht jedes Service bietet aufgrund fachlicher oder technischer Gegebenheiten (bei jeder Funktion) eine doppelte Namenslieferung an.
Beispiele:
Bei Abfragen der Ansprüche in die Vergangenheit mittels VDAS werden Daten aus einem Drittsystem geliefert – ohne Doppellieferung der Namensdaten bei abgeleiteten Ansprüchen.
Exkurs - das e-card-System:
Das e-card-System unterteilt sich in ein Zentralsystem, das in einem Rechenzentrum läuft und (aktuell) den Ordinationsclients, die direkt beim Vertragspartner untergebracht
sind. Der Ordinationsclient ist ein dedizierter Client (Hardware und Software) und ist die Schnittstelle zum Zentralsystem für die Endanwender beim Vertragspartner.
Die Vertragspartnersoftware wird ebenfalls über den Ordinationsclient eingebunden.
Mit dem Projekt GINAaaS erfolgt eine Schrittweise Umstellung der Services auf reine Server Projekte. D.h. es erfolgt eine Ablöse der GINA. Services die bereits umgestellt wurden, sind sowohl über die GINA als auch über den Server verfügbar. Neue Services werden nur über den GINA Proxy aufrufbar sein. Für die Produktion gilt: Der "direkte" Aufruf über den Server ist aktuell nur bei Verwendung des GINA Proxys möglich. Weitere Informationen über die Nutzung des GINA Proxys erhalten Sie auf Anfrage beim Partnersupport. In der VPSWH-Umgebung erfolgt ein direkter Zugriff auf die zentralisierten Services.
Überblick über die Komponenten des Gesamtsystems
Mit dem Projekt GINAaaS erfolgt eine Schrittweise Umstellung der Services auf reine Server Projekte. D.h. es erfolgt eine Ablöse der GINA. Services die bereits umgestellt wurden, sind sowohl über die GINA als auch über den Server verfügbar. Neue Services werden nur über den GINA Proxy aufrufbar sein. Für die Produktion gilt: Der "direkte" Aufruf über den Server ist aktuell nur bei Verwendung des GINA Proxys möglich. Weitere Informationen über die Nutzung des GINA Proxys erhalten Sie auf Anfrage beim Partnersupport. In der VPSWH-Umgebung erfolgt ein direkter Zugriff auf die zentralisierten Services.
Überblick über die Komponenten des Gesamtsystems
Die allgemeinen Komponenten des Gesamtsystems:
Ordinationsclient / GINA
LANCCR
Clientverwaltung, Softwareverteilung, Fernwartung
Mit dem Projekt GINAaaS erfolgt eine Schrittweise Umstellung der Services auf reine Zentralsystem Projekte.
D.h. es ist eine Ablöse der GINA geplant.
Bestehende Services die bereits umgestellt wurden, sind sowohl über die GINA als auch über den Server verfügbar. Neue Services werden nur über den GINA Proxy aufrufbar sein. Für die Produktion gilt: Der "direkte" Aufruf über den Server ist aktuell nur bei Verwendung des GINA Proxys möglich. In der VPSWH-Umgebung erfolgt ein direkter Zugriff auf die zentralisierten Services.
Weitere Informationen über die Nutzung des GINA Proxys erhalten Sie auf Anfrage beim Partnersupport.
Bestehende Services die bereits umgestellt wurden, sind sowohl über die GINA als auch über den Server verfügbar. Neue Services werden nur über den GINA Proxy aufrufbar sein. Für die Produktion gilt: Der "direkte" Aufruf über den Server ist aktuell nur bei Verwendung des GINA Proxys möglich. In der VPSWH-Umgebung erfolgt ein direkter Zugriff auf die zentralisierten Services.
Weitere Informationen über die Nutzung des GINA Proxys erhalten Sie auf Anfrage beim Partnersupport.
LANCCR
Diese Komponente ist für die Anbindung der Kartenleser verantwortlich und bietet Dienste zur Nutzung der Kartenfunktionen (z.B. Kartendaten lesen und
Signaturerstellung) an. Der LANCCR kann mittels REST Service verwendet werden.
Clientverwaltung, Softwareverteilung, Fernwartung
Die Softwareverteilung ist ein Mechanismus am Ordinationsclient, der zu bestimmten Zeitpunkten die Aktualität der Software am Ordinationsclient prüft und
falls erforderlich aktualisiert.
Die Clientverwaltung ist ein weiteres Subsystem des Zentralsystems. Insbesondere sind in diesem System alle erforderlichen Mechanismen zur Softwareverteilung (Updates) und deren Überwachung auf den Ordinationsclient zusammengefasst.
Mit Ablöse der GINA werden auch diese Mechanismen entfallen und bei Bedarf durch andere Mechanismen / Schnittstellen ersetzt.
Die Clientverwaltung ist ein weiteres Subsystem des Zentralsystems. Insbesondere sind in diesem System alle erforderlichen Mechanismen zur Softwareverteilung (Updates) und deren Überwachung auf den Ordinationsclient zusammengefasst.
Mit Ablöse der GINA werden auch diese Mechanismen entfallen und bei Bedarf durch andere Mechanismen / Schnittstellen ersetzt.