# Package at.chipkarte.client.elgaad.soap

Interface und Klassen des ELGA Adapters (ELGAAD).

See: Description

- Interface Summary
  Interface | Description
  --- | ---
  IElgaadService | Dieses Service stellt die Funktionalitï¿½ten des ELGA-Adapters (ELGAAD) Version 10 zur Verfï¿½gung.

- Class Summary
  Class | Description
  --- | ---
  Abgabe | Abgabedaten.
  AbgabeAendernErgebnis | Ergebnis der Funktion `abgabeAndern()`.
  AbgabenAbrufenErgebnis | Ergebnis der Funktion `abgabenAbrufen()`.
  AbgabenSpeichernErgebnis | Ergebnis der Funktion `abgabenSpeichern()`.
  AbgabeVerordnungAenderung | Änderungsdaten einer Abgabe oder Verordnung.
  Adresse | Adressdaten.
  AenderungsId | Map von VerordnungsId zur Dokument-ID der dazu erzeugten Pharmazeutischen Empfehlung.
  Ambulanzbefund |
  AmbulanzbefundAbfragenErgebnis |
  AmbulanzbefundAendernErgebnis |
  AmbulanzbefundEntry |
  AntikoerperBestimmung | Daten der Antikörper-Bestimmung.
  AntikoerperBestimmungBefundgruppe | Enthält die zu eine Befundgruppe (Impfung) gehörigen Untersuchungen für die Antikörperbestimmung.
  AntikoerperBestimmungUntersuchung | Informationen zur Untersuchung zur Antikörper-Bestimmung.
  Arznei | Daten einer Arznei.
  Arzneimittel | Daten eines Arzneimittels (im Gegensatz zu einer Magistralen Zubereitung, siehe `MagistraleZubereitung`).
  AssociationsObject | Relation eines Dokuments.
  AufzeichnendesGeraet | Daten zum aufzeichnenden Geräts.
  Author | Daten zum Author.
  AuthorBody | Daten zum Autor.
  AuthorPerson | Daten zur Person des Authors.
  BackendMeldung | Meldungsinformation aus dem jeweiligen Backend-System.
  BefundFilterkriterien | Filterkriterien für die Spezifizierung der Abfrage von Befunden (siehe Funktion `dokumentenuebersichtAbrufen()`).
  BefundPdfAufbereitenErgebnis | Ergebnis der Funktion `befundPdfAufbereiten()`.
  BerechtigterBearbeiter | Daten eines/r berechtigten Bearbeiters/in, der/die eine Korrektur vornehmen darf.
  CdaValue | Angabemöglichkeit für einen HL7 Value (siehe Leitfaden).
  ChildReference | Angabemöglichkeit für einen HL7 Value (siehe Leitfaden) als Child.
  Code | ELGA spezifische Codedefiniton.
  Custodian | Informationen zum Verwahrers des Dokuments.
  DokumentAbfrageErgebnis | Ergebnis der Funktion `dokumenteAbrufen()`.
  Dokumentenuebersicht | Ergebnis der Funktion `dokumentenuebersichtAbrufen()`.
  DokumenteStornierenErgebnis | Ergebnis der Funktion `dokumenteStornieren()`.
  DokumentId | Dokument Identifier Spezifizierungen.
  DokumentReferenz | Daten der Referenz auf ein anderes Dokument.
  Dosierung | Angaben zur Dosierung.
  Dosis | Angaben zur Dosis.
  Einnahmedauer | Einnahmedauer, wenn der Einnahmestart unbekannt ist.
  EintragendePerson | Daten der eintragenden Person (Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) ).
  Einzeldosierung | Angaben zur Einzeldosierung.
  EinzeldosierungTage | Angaben zur Einzeldosierung an bestimmten Tagen.
  ElgaBenutzer | Daten eines Benutzers der ELGA (natürliche Person).
  EmedIdErstellenErgebnis | Ergebnis der Funktion `emedIdErstellen()`.
  GdaAdresse | Adresse des GDAs.
  GdaDeskriptor | GDA Daten.
  Guardian | Daten zum Sachwalter/Vormund.
  Id | ID Spezifikation.
  ImmunisierungseintraegeAbrufenErgebnis | Ergebnis der Funktion `immunisierungseintraegeAbrufen()`.
  ImmunisierungseintraegeAktualisierenErgebnis | Ergebnis der Funktion `immunisierungseintraegeAktualisieren()`.
  ImmunisierungseintraegeSpeichernErgebnis | Ergebnis der Funktion `immunisierungseintraegeSpeichern()`.
  ImmunisierungseintraegeStornierenErgebnis | Ergebnis der Funktion `immunisierungseintraegeStornieren()`.
  ImmunisierungseintragFilterkriterien | Filterkriterien für die Suche nach Immunisierungseinträgen
  Immunisierungsstatus | Daten zum Immunisierungsstatus.
  Impfempfehlung | Daten zur Impfempfehlung.
  ImpfpassAbrufenErgebnis | Ergebnis der Funktion `impfpassAbrufen()`.
  ImpfpassPdfAufbereitenErgebnis | Ergebnis der Funktion `impfpassPdfAufbereiten()`.
  ImpfrelevanteErkrankung | Informationen zu einer Impfrelevanten Erkrankung
  Impfschema | Daten des Impfschemas
  Impfstoff | Daten eines Impfstoffes.
  ImpfstoffeSuchenErgebnis | Ergebnis der Funktion `impfstoffeSuchen()`.
  Impfung | Daten zur Impfung.
  ImpfungVerrechnungsinformation | Information über Impfgutscheine bzw.
  Impfziel | Daten des Impfzieles.
  Indikationsgruppen | Gibt an, welche Impfungen aufgrund der Zugehörigkeit des zu Impfenden zu einer bestimmten Personengruppe zu beachten sind.
  InstanceIdentifier | Instanzidentifier.
  InstanceIdentifierBase | Basisidentifier der Instanz.
  Kommentar | Kommenatardaten.
  Kontaktbestaetigung | Daten einer Kontaktbestätigung.
  KontaktbestaetigungErstellenErgebnis | Ergebnis der Funktionen `kontaktbestaetigungErstellen()` und `kontaktbestaetigungZuweisungErstellen()`.
  KorrigierendePerson | Daten der korrigierenden Person (Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) ).
  LegalAuthenticator | Daten des Unterzeichners.
  MagistraleZubereitung | Daten einer Magistralen Zubereitung (im Gegensatz zu einem `Arzneimittel`).
  MedikationFilterkriterien | Filterkriterien für die Suche nach e-Medikationsdaten.
  MedikationslisteAbfrufenErgebnis | Ergebnis der Funktion `medikationslisteAbrufen()`.
  Metadaten | Metadaten.
  NachtragendePerson | Daten der nachtragenden Person
  Name | Namensdaten einer Person.
  Ordination | Ordinationsadressdaten.
  Organization | Daten zur Institution des Authors.
  PatientInfo | Informationen zum Patienten.
  ProcedureEntry |
  Protokolleintrag | Protokolldaten zu einer erfolgreich durchgeführten Transaktion über das ELGAAD-Service.
  ReferenceId | Kann bei e-Befunden als Identifikator für einen gemeinsamen Dokumentenstamm verwendet werden (z.B. für verschiedene Versionen eines Dokuments).
  Rezept | Daten eines Rezeptes.
  RezeptAusstellenErgebnis | Ergebnis der Funktion `rezeptAusstellen()`.
  RezepteAbrufenErgebnis | Ergebnis der Funktion `rezepteAbrufen()`.
  Tagesdosierung | Angaben zur Tagesdosierung.
  TagesdosierungTage | Angaben zur Tagesdosierung an bestimmten Tagen.
  TeilnahmeStatus | Teilnahmestatus Informationen für eine Anwendung.
  TeilnahmeStatusAbfragenErgebnis | Ergebnis der Funktion `teilnahmeStatusAbfragen()`.
  Teilnehmer | Teilnehmerdaten.
  TransaktionsInfo | Beinhaltet Informationen zur ELGA-Transaktionsnummer.
  ValidierendePerson | Daten zur Validierenden Person.
  Verordnung | Verordnungsdaten.
  VerordnungenAbrufenErgebnis | Ergebnis der Funktion `verordnungenAbrufen()`.
  VerordnungenAendernErgebnis | Ergebnis der Funktion `verordnungenAendern()`.
  Verwandter | Daten zur verwandten Person.
  WeitereEmpfohleneMassnahmen |
  Zusatzinformation | Zusatzinformationen zu Verordnungen/Abgaben.

## Package at.chipkarte.client.elgaad.soap Description

Interface und Klassen des ELGA Adapters (ELGAAD). Enthält den SOAP-Endpoint `IElgaadService` sowie die dazu notwendigen Klassen.
Inhalt der ELGAAD package-Beschreibung:

- Allgemein

- Unterstützende Dokumentationen
- Rechte
- Online-/Offline-Status
- Informationen und Hinweise

- Dialogaufbau
- ELGAAD Request-/Responsevorgaben
- Authentifizierung und GDA-I
- Kontaktbestätigungen und ZP-I
- eMedId und eMedId-Assertion
- Impf-Assertion
- Impfempfehlungen
- SV-Nummer vs. e-card CardToken vs. eMedId
- Terminologiedaten
- Fehlerhandling
- Protokollierung der Funktionsaufrufe

- Funktionalität des ELGAAD-Service

- Abfrage der Medikationen, Befunde, Impfpass des Patienten
- Kontaktbestätiungen verwalten
- Ausstellen eines Rezeptes
- Abgaben speichern
- Immunierungseinträge (Impfpass) speichern
- Korrekturfälle
- Patientenkontakt delegieren
- Protokolldaten abrufen

# Allgemein

Der ELGA-Adapter bietet die Möglichkeit bestimmte ELGA-Funktionalitäten zu nutzen. Im Wesentlichen handelt es sich dabei um folgende:

- e-Medikation
- Abfrage von e-Befunden
- e-Impfpass

Im Fokus steht dabei eine an die bestehende SS12 angelehnte "einfach" gehaltene Schnittstelle, die vor der Verarbeitung komplexer IHE- bzw. WS-Trust-Requests oder CDA-Dokumenten abschirmt.
Der ELGA Adapter unterstützt keine schreibenden Zugriffe auf ELGA Bereiche (z.B. Speichern von Befunden).

## Unterstützende Dokumentationen

Der ELGA Adapter bietet eine "vereinfachte" Schnittstelle zur Nutzung der ELGA Funktionalitäten an.
Es gelten jedoch weiterhin die Vorgaben und Empfehlung von ELGA bzgl. der Einbindung der ELGA Funktionalitäten in die GDA-SW (zu unterstützende Abläufe, Usability, GUI Design, Umgang mit situativen OptOut, ...).
Beachten Sie daher bitte die Dokumentationen auf www.elga.gv.at.
Darunter fallen unter anderem:

- Implementierungsleitfäden
- Usability-Styleguides
- Organisationshandbücher
- Rechtliche Grundlagen

## Rechte

Mittels der Funktion getBerechtigungen() aus dem BASE-Service ist es möglich, die Rechte des Gesundheitsdiensteanbieters (GDA) abzufragen.
Der ELGA Adapter unterscheidet folgende Rechte:

- ELGAAD.CORE
- ELGAAD.AUTH
- ELGAAD.MEDIKATION
- ELGAAD.BEFUND
- ELGAAD.IMPFPASS

Funktionen | benötigte Rechte | Fehlermeldung bei Aufruf ohne die benötigten Rechte
--- | --- | ---
GDA mittels VPNR suchen GDA mittels Kriterien suchen GDAs mittels GDA-OIDs suchen Protokolldaten abrufen | ELGAAD.CORE | AccessException.MISSING_ELGAAD_CORE
Dokumente abrufen Dokumentenübersicht abrufen HCP-Assertion abfragen Kontaktbestätigung Patientenkontakt erstellen Kontaktbestätigung Zuweisung erstellen Kontaktbestätigungen abfragen | ELGAAD.CORE ELGAAD.AUTH | AccessException.MISSING_ELGAAD_CORE AccessException.MISSING_ELGAAD_AUTH
Abgaben abrufen Abgaben speichern Abgabe ändern Dokumente stornieren eMedId erstellen Medikationsliste abrufen Rezepte abrufen Rezept ausstellen Verordnungen ändern | ELGAAD.CORE ELGAAD.AUTH ELGAAD.MEDIKATION | AccessException.MISSING_ELGAAD_CORE AccessException.MISSING_ELGAAD_AUTH AccessException.MISSING_ELGAAD_MEDIKATION
Befund als PDF aufbereiten Kontaktbestätigung delegieren Verordnungen aus ärztlichem Entlassungsbrief abrufen | ELGAAD.CORE ELGAAD.AUTH ELGAAD.BEFUND | AccessException.MISSING_ELGAAD_CORE AccessException.MISSING_ELGAAD_AUTH AccessException.MISSING_ELGAAD_BEFUND
Medikamente suchen Wirkstoffe suchen | ELGAAD.CORE ELGAAD.MEDIKATION | AccessException.MISSING_ELGAAD_CORE AccessException.MISSING_ELGAAD_MEDIKATION
Immunisierungseinträge abrufen Immunisierungseinträge speichern Immunisierungseinträge aktualisieren Immunisierungseinträge stornieren Impfpass als PDF aufbereiten | ELGAAD.CORE ELGAAD.AUTH ELGAAD.IMPFPASS | AccessException.MISSING_ELGAAD_CORE AccessException.MISSING_ELGAAD_AUTH AccessException.MISSING_ELGAAD_IMPFPASS
Impfstoffe suchen Wirkstoffe suchen | ELGAAD.CORE ELGAAD.IMPFPASS | AccessException.MISSING_ELGAAD_CORE AccessException.MISSING_ELGAAD_IMPFPASS

Die Funktionen Dokumentenübersicht abrufen (dokumentenuebersichtAbrufen) und Dokumente abrufen (dokumentenuebersichtAbrufen()) benötigen zum Aufruf selbst nur die Rechte ELGAAD.CORE und ELGAAD.AUTH.
Es gilt jedoch:
Der Aufruf der Funktionen zur Abfrage von Dokumenten aus der e-Medikation ist nur möglich, wenn auch das Recht ELGAAD.MEDIKATION vorhanden ist.
Der Aufruf der Funktionen zur Abfrage von Befunden ist nur möglich, wenn auch das Recht ELGAAD.BEFUND vorhanden ist.
Der Aufruf der Funktionen zur Abfrage des e-Impfpasses ist nur möglich, wenn auch das Recht ELGAAD.IMPFPASS vorhanden ist.
Es werden in diesen Fällen keine AccessExceptions sondern ElgaadExceptions retourniert.

## Online-/Offline-Status

Ob eine Verbindung für ein bestimmtes Service zum e-card-Serversystem besteht, sollte im Normalbetrieb NICHT abgefragt werden! Die Abfrage sollte nur dann durchgeführt werden um festzustellen, ab wann das Service wieder online ist, wenn zuvor Verbindungsprobleme aufgetreten sind.
Die empfohlene Frequenz für die Abfragen liegt in diesem Fall bei > 1 Minute.
Die Abfrage ist über eine REST Schnittstelle durchzuführen:
GET https://services.ecard.sozialversicherung.at/<service-name>/<versionsnummer>/status (Produktions-Instanz) bzw. GET https://services-a.ecard-test.sozialversicherung.at/<service-name>/<versionsnummer>/status (VPSWH-Instanz)
Ist der Server erreichbar, wird der Response HTTP 200 retourniert. Im Offline-Fall wird keine Response retourniert.

## Informationen und Hinweise

#### Dialogaufbau

Für die meisten Funktionen des ELGA Adapters benötigt der GDA das Recht ELGA.AUTH (siehe hierzu auch das Kapitel Rechte).
Der GDA erhält dieses Recht wenn er einen Dialogaufbau unter Angabe von ELGA-Parametern durchführt. Die Parameter sind in der Dialogaufbau-Funktion setDialogAdress() enthalten. Weitere Informationen hinsichtlich der Angabe der Parameter entnehmen Sie bitte der AUTH Beschreibung.
Die beim Dialogaufbau angegebenen Daten werden innerhalb der ELGAAD Funktionen weiterverwendet (zwecks Authentifizierung Richtung ELGA). Beachten Sie bitte, dass die betroffenen Patienten per Portal Einsicht nehmen können wer wann auf Ihre Daten zugegriffen hat.
Sofern unterschiedliche Ärzte innerhalb einer Ordination / Standort arbeiten (z.B. Gruppenpraxis), sind unter Umständen mehrere Dialoge mit Benutzerspezifischen ELGA Parametern notwendig. Ein Dialog-Sharing darf in diesem Fall nicht stattfinden!
Siehe hierzu auch das Kapitel Authentifizierung und GDA-I.

#### ELGAAD Request-/Responsevorgaben

IHE
Die Funktionen des Adapters vereinfachen die geforderten IHE Strukturen auf bekannte SS12 Strukturen. Die erfolgt sowohl für die Request, als auch für die Responses.
CDA Dokumente
Prinzipiell werden vom Adapter keine CDA-Dokumente retourniert, sondern vereinfachte SS12-Datenstrukturen. Zusätzlich werden die IDs der durch den Adapter im Hintergrund verarbeiteten CDA-Dokumente zurückgeliefert.
Analog dazu werden vom Adapter keine CDA-Dokumente entgegengenommen, sondern bei Bedarf anhand der Request-Daten erzeugt. Dabei müssen alle notwendigen Daten von der GDA-SW versorgt werden, sodass der Adapter nicht auf zuvor gespeicherte Dokumente zurückgreifen muss.
Durch den Adapter in vereinfachter SS12-Form retournierte Dokumente der e-Medikation bilden den aktuellen Status des Dokuments inklusive aller bisher durchgeführten Änderungen ab. Das "Übereinanderlegen" von Pharmazeutische Empfehlungen (Pharmaceutical Advice - Abkürzung "PADV") erfolgt bereits durch den Adapter.
Dem Benutzer werden die aktuell gültigen Daten eines Dokuments retourniert werden. In diesen Daten scheint jedoch nicht auf, welche Änderungen durch welchen Benutzer zu welchem Zeitpunkt durchgeführt worden sind (analog zu traditionellen, nicht dokumentenbasierten Systemen).
Hinweis: Beim Ändern von e-Medikations-Dokumenten werden lediglich die IDs der erstellten PADV-Dokumente retourniert und nicht die aktualisierten Objektstrukturen.
Hinweis: Beim Ändern von e-Impfpass-Dokumenten werden die aktualisierten Objektstrukturen retourniert.
Eine Ausnahme bzgl. der Retournierung von CDA-Dokumenten stellt die generische Funktion dokumenteAbrufen() (siehe Dokumente abrufen) dar, über die mittels Dokument-ID CDA-Dokumente (als MTOM-Attachments) abgefragt werden können.
Diese Funktion ist insbesondere für die Abfrage von e-Befunden relevant, da in diesem Bereich derzeit keine vereinfachten Strukturen durch den ELGA-Adapter zur Verfügung gestellt werden.
Requestgröße
Requests an den ELGA Adapter unterliegen der Defaultbeschränkung von aktuell 3MB.
Hinweis: Aktuell beinhaltet der ELGA Adapter keine Funktion zum Hochladen von Attachments. Somit ist diese Begrenzung eher theoretisch zu sehen.
Attachmenthandling
Aktuell bietet der ELGA Adapter folgende Funktionen an, bei denen die Retournierung eines Attachments möglich ist:

- rezeptAusstellen() - siehe Rezept Ausstellen
- dokumenteAbrufen() - siehe Dokumente abrufen
- befundPdfAufbereiten() - siehe Befund als PDF aufbereiten
- emedIdErstellen() - siehe eMedId erstellen
- impfpassPdfAufbereiten() - siehe Impfpass als PDF aufbereiten

Die Funktion rezeptAusstellen() kann, bei erfolgreicher Rezepterstellung, als Rückgabe sowohl das Rezept, als auch den eventuell erstellten DataMatrix-Code zurückliefern. Der DataMatrix-Code wird dabei als PNG mittels MTOM retourniert.
Die Funktion dokumenteAbrufen() retourniert, bei erfolgreicher Abfrage, als Rückgabe die ermittelten Dokumente als ZIP mittels MTOM. Die Dateien innerhalb des ZIP Archivs erhalten als Namen die uniqueId der jeweiliges zugehörigen DokumentId.
Die Funktion befundPdfAufbereiten() retourniert, bei erfolgreicher Abfrage, als Rückgabe das erstellte PDF mittels MTOM zurück.
Die Funktion emedIdErstellen() retourniert, bei erfolgreicher Abfrage, zusätzlich zur erstellten emedId den eventuell erzeugten DataMatrix-Code als PNG mittels MTOM.
Die Funktion impfpassPdfAufbereiten() retourniert, bei erfolgreicher Abfrage, als Rückgabe das erstellte PDF mittels MTOM zurück.
Die maximale Zahl an Dokumenten die gleichzeitig mittels der Funktion abgefragt werden können, wird anhand der Responsegröße gegenüber dem ELGA Backend begrenzt. Diese ist aktuell auf insgesamt 10 MB begrenzt.
Hinweis: Um die notwendigen DokumentIds für die Abfrage der Dokumente zu erhalten, kann die Funktion dokumentenuebersichtAbrufen() (siehe Dokumentenübersicht Abrufen) genutzt werden. Diese Funktion retourniert die Metadaten der vorhandenen Dokumente, in denen unter anderen die Größe des jeweiligen Dokuments enthalten ist. Bei Abfrage von Dokumente empfiehlt es sich vor dem Request eine Kontrolle durchzuführen ob die Summe der einzelnen Dateigrößen der abzurufenden Dokumente unterhalb 10MB liegt. Bei einer Summe nahe oder über 10MB wird empfohlen für die Abfrage mehrere Requests zur Abfrage zu verwenden.
Generelle Informationen bzgl. SOAP-Attachment mittels MTOM siehe Abschnitt "Attachments" in Overview .

#### Authentifizierung und GDA-I

Die Authentifizierung des GDAs im e-card System findet beim Dialogaufbau statt. Soll ein Dialog auch für die Nutzung von ELGAAD-Funktionen zur Verfügung stehen, sind beim Dialogaufbau entsprechende ELGA Parameter anzugeben. Beim ersten entsprechenden ELGAAD Funktionsaufruf für den GDA, erfolgt die Authentifizierung des GDAs gegenüber ELGA.
Damit der GDA gegenüber ELGA authentifiziert werden kann, muss der GDA

- generell im Gesundheitsdiensteanbieter-Index (GDA-I) vorhanden sein, sowie
- die beim Dialogaufbau angegebene ELGA-Rolle besitzen.

Die Verwaltung der Authentifizierung erfolgt bei Nutzung des ELGA Adapters implizit und muss nicht durch die GDA-SW erfolgen.
Damit der ELGA Adapter den Benutzer entsprechend Authentifizieren kann, werden die beim Dialogaufbau angegebenen ELGA Parameter herangezogen:

- Für die Ausstellung des ELGA Authentifizierungstickets (STS) werden wahlweise die Parameter aus dem Objekt GDAMA bzw. Prozess verwendet.
- Der Parameter ElgaRolle wird in der weiterführenden Ausstellung der HCP-Assertion verwendet.

In der Regel erfolgt die Authentifizierung mittels HCP-Assertion. Diese wird nach Ausstellung für die weitere Verwendung innerhalb des ELGA Adapters verwaltet. Bei Bedarf (Ablauf der Gültigkeit der HCP-Assertion) wird automatisch eine neue angefordert.
Schlägt die Ausstellung einer HCP-Assertion fehlt, wird eine entsprechende Fehlermeldung ausgegeben. Die Nutzung der aufgerufenen ELGAAD Funktion ist in diesem Fall nicht möglich!
DDurch die Beendung des Dialogs wird auch die entsprechende HCP Assertion beendet.urch die Beendung des Dialogs wird auch die entsprechende HCP Assertion beendet.
Für die ELGA-Rolle "Arbeitsmediziner" und "Amtsarzt" wird keine HCP-Assertion ausgestellt. F¨r GDAs die sich mit einer dieser ELGA-Rollen anmelden gilt: Im Zuge der jeweiligen aufgerufenen Funktion wird eine entsprechende Assertion ausgestellt (siehe hierzu auch das Kapitel Impf-Assertion).
Bei Retournierung der Fehlermeldung ElgaadException.ROLE_WRONG_OR_GDA_UNKOWN im Zuge der Ausstellung einer Assertion ist der GDA entweder im GDA-I nicht enthalten oder er ist nicht mit der beim Dialogaufbau angegebenen Elga-Rolle eingetragen. Überprüfen Sie im Zweifelsfall ob dem Dialog die richtige ELGA-Rolle beim Dialogaufbau angegeben wurde und bauen Sie bei Bedarf einen neuen Dialog mit der richtigen ELGA-Rolle auf.
Hinweis: Die ELGA-Rolle des GDAs kann nur beim Dialogaufbau angegeben werden!

#### Kontaktbestätigungen und ZPI

Bestimmte Funktionalitäten die der ELGA Adapter anbietet, benötigen einen Nachweis, dass zwischen den GDA und dem Patienten ein Kontakt stattgefunden hat (Patientenkontakt/Zuweisungskontakt).
Die Verwaltung der für ELGA eingemeldeten Patienten-/Zuweisungskontakte übernimmt das KBS (Kontaktbestätigungsservice).
Patientenkontakt
Um für einen GDA einen Patientenkontakt in das KBS einzumelden, kann das STS Service verwendet werden. Hier werden spezielle Kontaktbestätigungstickets für ELGA zur Verfügung gestellt. Die Möglichkeit einen Patientenkontakt einzumelden steht allen ELGA-Rollen zur Verfügung.
Im Rahmen der Nutzung des ELGA Adapters wird die Einmeldung einer Patientenkontaktbestätigung automatisch durch den Adapter vorgenommen. D.h. dies muss nicht von der GDA-SW umgesetzt werden. Es gibt allerdings Anwendungsfälle für die es notwendig ist, eine Patientenkontaktbestätigung explizit zu erstellen. Zu diesem Zweck steht die Funktion Patientenkontaktbestätigung erstellen zur Verfügung.
Zur Einmeldung des Patientenkontaktes, im Zuge der Nutzung der ELGAAD Funktionalität, wird das STS Ticket "ecard-only" verwendet. Genaue Informationen hinsichtlich des STS Tickets entnehmen Sie bitte der STS Servicebeschreibung.
Bei der Ticketausstellung wird versucht, einen Patientenkontakt mittels folgender Mittel nachzuweisen:

- angegebenes e-card CardToken
- Konsultation mit e-card
- Versichertendatenabfrage mit e-card

Bzgl. der Verwendung eines e-card CardTokens, siehe auch das Kapitel Zugriff auf die e-card des Patienten - Erstellen eines e-card Cardtokens.
Sofern ein entsprechender Patientenkontakt im eCS nachgewiesen werden kann, wird die Patientenkontaktbestätigung an das KBS eingemeldet. Dabei wird der Bestätigungstyp automatisch mit K102 (Ambulant) belegt.
Die Information hinsichtlich der Einmeldung des Kontaktes an das KBS wird durch den ELGA Adapter verwaltet. Bei Bedarf (Ablauf der minimalen Gültigkeit der erlaubten Zugriffsdauer) wird geprüft, ob bereits ein neuerer Kontakt (als der zuletzt gemeldete Kontakt) vorhanden ist und eine neue Einmeldung ans KBS durchgeführt. Es ist zu beachten, dass dieses Verhalten auch bei Durchführung der Funktion Kontaktbestätigung erstellen gilt. D.h, es wird auch hier nur dann eine neue Einmeldung ans KBS durchgeführt, wenn der entsprechende Bedarf zur Neumeldung erkannt wurde.
Hinweis: Es ist zu unterscheiden zwischen der Zeitdauer die ein Kontakt zurückliegen darf und der Zeitdauer des Zugriffs aufgrund eines Kontaktes. Generell ist es nicht notwendig vor jedem ELGAAD Request zwingend einen Kontakt im e-card System zu erzeugen, da Kontakte eine gewisse Zeit in der Vergangenheit liegen können. So kann zum Beispiel bei einer Ärztlichen Untersuchung bei der eine Konsultation mit e-card erfasst wurde, mehrere Rezepte aufgrund dieses einen Kontaktes erfasst werden!
Die Minimale Zugriffsdauer wird vom Adapter verwendet um die Einmeldungen von Kontaktbestätigungen ins ELGA-KBS zu verwalten. Es wird dabei von der minimalen Gültigkeitsdauer ausgegangen. Erst nach Ablauf dieses Zeitraums wird erneut die Einmeldung des Patientenkontaktes ins KBS angestoßen. Somit werden die Funktionsaufrufe für den Benutzer performanter (da nicht jeder einzelne Request immer automatisch zu einer Kontaktbestätigung führt).
Das bedeutet aber auch, dass nicht jedes "e-card stecken" automatisch zur Einmeldung eines neuen Kontaktes ins ELGA-KBS führt.
Der Adapter stellt keine Funktionalität zur Verfügung um durch den Adapter eingemeldete Kontaktbestätigungen im KBS zu stornieren!
Auch wenn der Adapter Informationen hinsichtlich Einmeldungen verwaltet, ist das KBS die Entscheidende Stelle ob ein Kontakt zum Zugriff (lesend/schreibend) verwendet werden kann.
Zuweisungskontakt
Um für einen GDA einen Zuweisungskontakt in das KBS einzumelden, wird eine explizite Funktion zur Verfügung gestellt. Die Möglichkeit einen Zuweisungskontakt einzumelden steht nur der ELGA Rolle "Labor und Pathologie" zur Verfügung.
Im Gegensatz zum Patientenkontakts (implizite Ausstellung) muss die Einmeldung eines Zuweisungskontakts immer explizit erfolgen. Zu diesem Zweck steht die Funktion Zuweisungskontaktbestätigung erstellen zur Verfügung.
Das KBS kann Kontaktbestätigungen besitzen, die nicht in der Verwaltungslogik des Adapters bekannt sind (z.B. durch Delegierung des Kontaktes) bzw. Informationen, warum trotz bestehenden Kontaktes kein Zugriff möglich ist (z.B. der Patient hat den GDA aktuell gesperrt).
Die Prüfung ob ein Kontakt wirklich zulässig ist, findet daher immer erst bei tatsächlicher Notwendigkeit gegen das KBS statt. Diese Prüfung wird nicht durch den ELGA Adapter selbst durchgeführt. D.h. im Fehlerfall erfolgt kein Funktionsabbruch mit einer eCS Exception, sondern es werden die entsprechenden Backendinformationen weitergegeben (siehe hierzu Kapitel Fehlerhandling).
Hinweis: Der Patient muss für die Einmeldung einer Kontaktbestätigung im Zentralen Patientenindex (ZP-I) eingetragen sein. Kann für den Patienten kein bPK-GH im ZP-I ermittelt werden, erfolgt ein Funktionsabbruch mit der Exception ElgaadException.KB_NO_BPKGH_ERROR.
Der Adapter stellt für die GDA-SWH eine Funktion zur Abfrage der Kontaktbestätigungen zur Verfügung - siehe Kontaktbestätigungen abrufen. Es werden dabei die Kontaktbestätigungen zu einem bestimmten Patienten (mittels SV-Nummer bzw. e-card CardToken anzugeben) ermittelt, bei denen der abfragende GDA involviert ist.
Es werden folgende Kontaktbestätigungen ermittelt:

- Die Kontaktbestätigung wurde vom abfragenden GDA für sich als behandelnden GDA eingemeldet.
- Die Kontaktbestätigung wurde vom abfragenden GDA eingemeldet und an einen anderen GDA delegiert.
- Die Kontaktbestätigung wurde von einen anderen GDA eingemeldet und an den abfragenden GDA delegiert.

Dabei können entweder alle oder nur die aktuell aktive Kontaktbestätigung des Patienten abgefragt werden bei denen der GDA involviert ist. Die Daten werden aus dem KBS ermittelt. Es werden dabei sowohl Patientenkontaktbestätigungen, wie auch Zuweisungskontaktbestätigungen berücksichtigt.

#### eMedId und eMedId-Assertion

Im Zuge der Ausstellung eines Rezeptes, dem Speicherung von Abgaben bzw. dem Ändern von Verordnungen / Abgaben werden automatisch eMedIds erzeugt. D.h. es muss keine Erzeugung und Verwaltung von eMedIds durch die GDA-SW erfolgen.
Ein Spezialfall ist das Ausstellen von Rezepten, denn für diese Funktion kann optional eine zu verwendende eMedId als Parameter übergeben werden.
Die Erzeugung von eMedId-Assertions erfolgt bei Bedarf automatisch durch den ELGA Adapter anhand der eingegebenen eMedId und muss nicht durch die GDA-SW erfolgen.
Sofern die Erstellung erfolgreich durchgeführt werden kann, wird die eMedId-Assertion durch den ELGA Adapter für die weitere Verwendung verwaltet.
Bei Bedarf (Ablauf der Gültigkeit) wird eine neue Assertion angelegt.

#### Impf-Assertion

Für den Zugriff auf Daten des e-Impfpasses (Abfragen, Speichern, Korrekturen) wird eine Impf-Assertion benötigt.
Die Erzeugung einer benötigten Impf-Assertion erfolgt bei Bedarf automatisch durch den ELGA Adapter anhand einer bestehenden bzw. automatisch angelegten HCP-Assertion (siehe Kapitel Authentifizierung und GDA-I). Eine aufgrund einer HCP-Assertion ausgestellte Impf-Assertion besitzt dieselbe Gültigkeit wie die dazugehörige HCP-Assertion.
Für bestimmte ELGA-Rollen ist das Vorhandensein einer HCP-Assertion keine Voraussetzung (siehe Kapitel Authentifizierung und GDA-I). Für diese Rollen wird eine Impf-Assertion unabhängig einer HCP-Assertion angelegt.
Sofern die Erstellung erfolgreich durchgeführt werden kann, wird die Impf-Assertion durch den ELGA Adapter für die weitere Verwendung verwaltet.
Generell gilt: Bei Bedarf werden Impf-Assertion (und wenn benötigt HCP-Assertion) automatisch durch den ELGA-Adapter neu ausgestellt.

#### Impfempfehlungen

Die ELGA GmbH bittet um folgenden Hinweis:
Solange die fachliche Validierung der persönlichen Impfempfehlungen (Impfkalender) noch nicht abgeschlossen ist, sind diese in der Anwendersoftware bis auf Weiteres nicht zu berücksichtigen.
Für eine inhaltliche Korrektheit wird keine Haftung übernommen.
Die Impfempfehlungen, welche im Impfpass-CDA Dokument bzw. an der SS12 Schnittstelle via ELGAAD-Service zurückgeliefert werden, sind bis auf Weiteres nicht zu berücksichtigen.
Im ELGA-Portal beziehungsweise bei der Verwendung des Stylesheets zur Anzeige der Impfdaten, wird die Anzeige der Empfehlungen unterdrückt. Wenn Sie in Ihrer Software aufgrund der zurückgelieferten Daten eine individuelle Anzeige der Daten implementieren, bitten wir Sie, diesen Umstand zu berücksichtigen und die Anzeige der Impfempfehlungen zu unterdrücken.

#### SV-Nummer vs. e-card CardToken vs. eMedId

Bei den ELGAAD Funktionen unterscheidet man folgende unterschiedliche Eingabevarianten:

- Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken
- Funktionen mit optionaler Angabe SV-Nummer/e-card CardToken
- Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken oder eMedId
- Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken und optionaler eMedId Angabe

Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken
Darunter fallen folgende ELGAAD Funktionen:

- dokumentenuebersichtAbrufen()
- medikationslisteAbrufen()
- verordnungenAbrufen()
- kontaktbestaetigungErstellen()
- kontaktbestaetigungDelegieren()
- verordnungAendern()
- befundPdfAufbereiten()
- kontaktbestaetigungenAbfragen()
- immunisierungseintraegeAbfragen()
- immunisierungseintraegeSpeichern()
- immunisierungseintraegeAktualisieren()
- immunisierungseintraegeStornieren()
- impfpassPdfAufbereiten()

Für diese Funktionen gilt:
Es muss zwingend eine SV-Nummer des Patienten angegeben werden. Dies kann entweder über die Angabe der SV-Nummer oder des e-card CardTokens erfolgen.
Bzgl. der Verwendung eines e-card CardTokens, siehe auch das Kapitel Zugriff auf die e-card des Patienten - Erstellen eines e-card Cardtokens.
Funktionen mit optionaler Angabe SV-Nummer/e-card CardToken
Darunter fallen folgende ELGAAD Funktionen:

- emedIdErstellen()

Für diese Funktionen gilt:
Es kann eine SV-Nummer des Patienten angegeben werden. Dies kann entweder über die Angabe der SV-Nummer oder des e-card CardTokens erfolgen.
Bzgl. der Verwendung eines e-card CardTokens, siehe auch das Kapitel Zugriff auf die e-card des Patienten - Erstellen eines e-card Cardtokens.
Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken oder eMedId
Darunter fallen folgende ELGAAD Funktionen:

- dokumenteAbrufen()
- rezepteAbrufen()
- abgabenAbrufen()
- abgabenSpeichern()
- abgabeAendern()
- dokumenteStornieren()

Für diese Funktionen gilt:
Es kann eine SV-Nummer des Patienten oder eine eMedId angegeben werden.
Für die Angabe der SV-Nummer gilt:
Dies kann entweder über die Angabe der SV-Nummer oder des e-card CardTokens erfolgen.
Bzgl. der Verwendung eines e-card CardTokens, siehe auch das Kapitel Zugriff auf die e-card des Patienten - Erstellen eines e-card Cardtokens.
Wird stattdessen eine eMedId angegeben, gilt:
In diesem Fall ist die Angabe des Patienten mittels SV-Nummer/e-card CardToken nicht mehr zulässig. D.h. der Parameter SV-Nummer darf nicht angegeben werden.
Hinweis: Wird keine eMedId angegeben, ist zwingend eine SV-Nummer bzw. ein e-card CardToken anzugeben.
Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken und optionaler eMedId Angabe
Darunter fallen folgende ELGAAD Funktionen:

- rezeptAusstellen()

Für diese Funktionen gilt:
Es muss eine SV-Nummer des Patienten angegeben werden. Zusätzlich kann eine eMedId angegeben werden.
Für die Angabe der SV-Nummer gilt:
Dies kann entweder über die Angabe der SV-Nummer oder des e-card CardTokens erfolgen.
Bzgl. der Verwendung eines e-card CardTokens, siehe auch das Kapitel Zugriff auf die e-card des Patienten - Erstellen eines e-card Cardtokens.
Hinweis: Es erfolgt in der e-Medikation eine Prüfung statt ob bei der Generierung der eMedId eine SV-Nummer angegeben wurde. Wenn ja, wird überprüft ob die zur eMedId gehörende SV-Nummer ident zur angegeben (bzw. anhand des e-card CardToken ermittelte) SV-Nummer ist. Ist dies nicht der Fall, wird eine entsprechende Fehlermeldung als BackendMeldung retourniert!

#### Zugriff auf die e-card des Patienten - Erstellen eines e-card Cardtokens

Das e-card Cardtoken (SV-Signaturtoken mit e-card) kann mittels die REST Schnittstelle vom LANCCR angefordert werden.
Die Dokumentation des REST-Services zur Kommunikation mit dem Kartenleser ist zu finden unter: Swagger Doku LANCCR.
Bei der Anmeldung des Patienten kann in Abhängigkeit davon ob eine e-card vorhanden ist ein e-card Cardtoken (SV-Signaturtoken mit e-card) oder ein o-card Cardtoken (SV-Signaturtoken mit Admin-Karte) ausgestellt werden.
Das ausgestellte Cardtoken kann anschließend in den Funktionen der jeweiligen Services anstelle einer (gesteckten) e-card verwendet werden.
Das Stecken der e-card zum Ausführen der jeweiligen Servicefunktion ist nicht mehr notwendig.
Das Cardtoken kann je nach Service für eine bestimmte Dauer nach Ausstellung genutzt werden. In der Regel ist ein ausgestellter CardToken für 10 Stunden verwendbar.
Welcher Cardtoken vom jeweiligen Service unterstützt wird, ist bei den Services selbst definiert.
In ELGAAD wird nur das e-card Cardtoken unterstützt!
Wurde bei einer Funktion eine SV-Nummer und ein e-card Cardtoken angegeben, müssen die eingegebene SV-Nummer und die SV-Nummer zu dem der e-card Cardtoken erstellt wurde ident sein, anderenfalls wird ein Fehler zurückgeliefert.

#### Terminologiedaten

Terminologien, die der Benutzer für die Erstellung von Dokumenten benötigt (wie z.B. ELGA_MedikationRezeptart_VS, Dokumententyp, GDA-Rolle, ...), müssen durch die GDA-SW bereitgestellt werden (entweder durch direkte Abfrage des Terminologieservers, oder durch Aktualisierung der Software durch den Hersteller).
Prüfungen auf geänderte Terminologien und somit eine Aktualisierung der verwendeten Terminologiedaten sollten mindestens wöchentlich erfolgen. Beachten Sie hierzu auch unbedingt die Beschreibungen und Vorgaben im entsprechenden Leitfaden unter www.elga.gv.at.
Für Arzneimittel der e-Medikation führt der ELGA Adapter eine Anreichung der Daten durch (Handelsname, Wirkstoffe,...). Bei der Erfassung einer Arznei ist nur die PZN anzugeben.
Zusätzlich kann mittels der Funktion medikamenteSuchen() auf die Daten der Arzneispezialitäten (ASP) - Liste bzw. mittels der Funktion wirkstoffeSuchen() auf die Daten der ATC-Code WIdO - Liste zugegriffen werden.
Mittels der Funktion impfstoffeSuchen() kann auf die Daten der Impfstoff - Liste (eImpf_Impfstoffe), sowie der historischen Impfstoffe (eImpf_HistorischeImpfstoffe) zugegriffen werden.
Bei der Angabe von Impfstoffen im Rahmen des e-Impfpasses ist die alleinige Angabe der PZN nicht zulässig.
Anhand des Impstoffes sind aus der Zuordnungsmatrix (eImpf_Zuordnungsmatrix), anhand der Zulassungsnummer die zulässigen Impfschema- und Impfdosis-Daten zu ermitteln. Wird kein Impfschema bei der Erfassung/Aktualisierung angegeben, gelten alle ermittelten Impfdosis-Werte für den Impfstoff. Wird zusätzlich bei der Erfassung/Aktualisierung der Impfung auch ein Impfschema angegeben (weil es sich nicht um das Standardschema handelt), sind nur noch solche Impfdosis-Werte für die Eingabe zulässig die zum gewählten Impfschema zugeordnet sind.

#### Fehlerhandling

Retournierung von Fehlern/Warnungen
Die Funktionen des ELGAAD Services können folgende Fehler retournieren:

- Fehler des e-card Systems
- Fehler/Warnungen aus den entsprechenden Backends

Sowohl die Prüfungen, wie auch die Verarbeitungen und Ermittlungen sind beim ELGA Adapter über mehrere Systeme verteilt.
Im e-card System erkannte Fehler werden in gewohnter Weise übermittelt (z.B. CardException, DialogExcpetion, ElgaadException, ...).
Fehler/Warnungen aus den Backends werden als BackendMeldungen in den Rückgabeobjekten der Funktionen übermittelt.
ValidierungsId
Die Objekte

- Abgabe
- Code
- Verordnung
- AbgabeVerordnungAenderung

bieten die Möglichkeit eine ValidierungsId anzugeben.
Wird in einer Funktion eine Liste von Objekten übergeben (z.B. mehrere Abgaben im Zuge von abgabenSpeichern()), kann in jedes einzelne Objekt von der GDA-SW eine eindeutige ValidierungsId gesetzt werden. Wird im Zuge der weiteren Verarbeitung ein Fehler festgestellt innerhalb eines der Objekte aus der Liste, wird im Fehler die ValidierungsId des betroffenen Objekts mitretourniert.
Dies gilt sowohl bei Fehlern die direkt durch das e-card-System erkannt werden, als auch bei Fehlern/Warnungen der Backends.
Die ValidierungsId wird nur mitgeliefert wenn:

- diese durch die GDA-SW angegeben wurde
- die Meldung einer Struktur zuordbar ist

Die Versorgung der Id in den jeweiligen Objekten, auch die Sicherstellung, dass die Ids (zumindest innerhalb des Requests) eindeutig sind, liegt in der Verantwortung der GDA-SW.
Beispiel: Speichern von Abgaben unter Angabe von 3 Abgaben
Abgabe 1 mit ValidierungsId "a", Abgabe 2 mit ValidierungsId "b", Abgabe 3 mit ValidierungsId "c"
Im Zuge der Validierung im e-card-System wird bei Abgabe 3 festgestellt, dass das Format von "Einnahmestart" ungültig ist. Der Benutzer erhält den Fehler ElgaadInvalidParameterException.EINNAHME_START_WRONG_FORMAT und als zusätzliche Information innerhalb der Exception die ValidierungsId gleich "c".
Zusätzlich wird die ValidierungsId von Verordnungen und Abgaben bei deren erfolgreicher Erstellung aus dem Request in den Response übernommen, um dem Aufrufer die Verknüpfung dieser Daten zu vereinfachen.
BackendMeldung
Jede Funktion mit Backend-Kommunikation hat in den Ausgangsdaten der Funktion die Möglichkeit eine Liste an BackendMeldungen zu retournieren. Dabei gilt, dass nur dann BackendMeldungen retourniert werden, wenn keine Fehlermeldung des e-card Systems retourniert wird.
Eine BackendMeldung enthält dabei immer die originalen Meldungen des Backends in unveränderter Form.
Bestimmte BackendMeldungen werden durch den Adapter zusätzlich mit einem AdapterCode und einem AdapterText versehen um die Fehlerursache verständlicher zu präsentieren.
Eine Liste der möglichen AdapterCodes finden Sie in der ELGAAD Javadoc unter der Konstante AdapterCodeConstants.
Wie bereits oben unter ValidierungsId beschrieben, wird auch bei BackendMeldungen die ValidierungsId des betroffenen Listen-Objekts mitgegeben, sofern die ValidierungsId durch die GDA-SW angegeben wurde und der Fehler genau dem Objekt zuordbar ist.
ELGA-Transaktionsinfo
Beim Auftreten bestimmter Fehlermeldungen des e-card Serversystems (ZS-Meldungen), sowie bei Backend-Meldungen vom Typ Error werden ELGA-Transaktionsinformationen mitgeliefert.
Im Falle eines eCS Serverfehlermeldungen wird die Transaktionsinformation innerhalb des ElgaadExceptionContent, bei Backend-Meldungen im Objekt der Backend-Meldung retourniert.
Die ELGA-Transaktionsinfo enthält dabei folgende Informationen:

- Transaktionsnummer (ID)
- Generierungszeitpunkt der Transaktionsnummer

Geben Sie diese Informationen im Falle der Meldung eines Fehlers an die ELGA Serviceline bitte umbedingt weiter. Weitere Informationen bzgl. der Übermittlung eines Fehlerreports an die ELGA-Serviceline können Sie der entsprechenden Dokumentation im Downloadbereich für Softwarehersteller (auf www.chipkarte.at) entnehmen.

#### Protokollierung der Funktionsaufrufe

Erfolgreiche Funktionsaufrufe des ELGA Adapters (= Funktionsaufrufe die nicht mit einer Fehlermeldung des e-card Systems beendet werden) werden im e-card System explizit protokolliert. Dies gilt sowohl für Funktionsaufrufe über die SS12, als auch für Funktionsaufrufe über die e-card WEB-GUI.
Es werden dabei nur die Aufrufe der ELGAAD Funktionen protokolliert und nicht die dahinter aufgerufenen Backend-Funktionen (z.B. der e-Medikation).
Aufrufe für ELGA die nicht über die SS12 oder die WEB-GUI erfolgen, werden hier nicht protokolliert (z.B. bei Verwendung des ELGA Proxys).
In den Protokolleinträgen wird unter anderen die zum Dialogaufbau verwendete o-card, sowie die beim Dialogaufbau angegebene natürliche Person gespeichert.
Die Protokolleinträge können mittels der Funktion protokolldatenAbrufen abgefragt werden. Im Zweifelsfalls kann anhand des Protokolleintrags festgestellt werden, welcher Mitarbeiter den Aufruf getätigt hat.
Die Anzahl der in einer Abfrage retournierten Protokolleinträge ist begrenzt. Wird die Fehlermeldung Elgaad.MAX_RESULTS_EXCEEDED retourniert, müssen die Selektionskriterien der Funktion zur Einschränkung der Suchergebnisse verwendet werden.

# Funktionalität des ELGAAD-Service

- Abfrage der Medikationen, Befunde, Impfpass des Patienten

- Dokumentenübersicht abrufen
- Dokumente abrufen
- Befund als PDF aufbereiten
- Medikationsliste abrufen
- Verordnungen aus ärztlichem Entlassungsbrief abrufen
- Rezepte abrufen
- Abgaben abrufen
- Immunisierungseinträge abrufen
- Impfpass als PDF aufbereiten

- Kontaktbestätigungen verwalten

- Kontaktbestätigungen abrufen
- Patientenkontaktbestätigung erstellen
- Zuweisungskontaktbestätigung erstellen

- Ausstellen eines Rezeptes

- Medikamente suchen
- Wirkstoffe suchen
- eMedId erstellen
- Rezept ausstellen

- Abgaben speichern

- Abgaben speichern

- Impfpass / Impfungen speichern

- Impfstoffe suchen
- Immunierungseinträge speichern

- Korrekturfälle

- Verordnungen ändern
- Abgabe ändern
- Immunisierungseinträge aktualisieren
- Immunisierungseinträge stornieren

- Patientenkontakt delegieren

- GDA mittels VPNR suchen
- GDA mittels Kriterien suchen
- GDAs mittels OIDs suchen
- Kontaktbestätigung delegieren

- Protokolldaten abrufen

- Protokolldaten abrufen

- Assertion abrufen

- HCP-Assertion abrufen

Die Beschreibung der Ein-und Ausgangsparameter der Funktionen sind der Interface-, sowie den Objektbeschreibungen in der ELGAAD Javadoc zu entnehmen.

## Abfrage der Medikationen, Befunde, Impfpass des Patienten

### Dokumentenübersicht abrufen

Die Funktion dokumentenuebersichtAbrufen() ermittelt eine Übersicht der e-Befunde und/oder der Medikationsliste und/oder der e-Impfpass-Dokumente des Patienten.
Per Boolschen Parametern kann angegeben werden ob nur e-Befunde, nur die Medikationsliste, nur die Impfpass-Daten oder alle drei abgerufen werden soll. Die Abfrage der Medikationsliste ist jedoch nur zulässig wenn der Benutzer das Recht ELGAAD.MEDIKATION besitzt. Die Abfrage der Befunde ist nur zulässig wenn der Benutzer das Recht ELGAAD.BEFUND besitzt.
Die Abfrage von e-Impfpass-Dokumenten ist nur zulässig wenn der Benutzer das Recht ELGAAD.IMPFPASS besitzt.
Für die Abfrage der e-Befunde stehen zusätzliche Selektionskriterien zur Verfügung.
Beachten Sie bitte, dass die Boolschen Parameter optional anzugeben sind, bei Nichtangabe wird automatisch der Defaultwert "true" angenommen. Besitzt der Benutzer in diesem Fall nicht das zur Abfrage benötigte Recht, wird die Funktion mit einer Fehlermeldung abgebrochen!
Es werden nur die Metadaten der gefundenen Dokumente retourniert.
Eine Abfrage der Dokumente selbst (als CDA) kann mittels der Funktion dokumenteAbrufen() (siehe Dokumente abrufen) durchgeführt werden.
Für die Abfrage der kompletten Medikationsliste (in SS12 Format als Abgabe- und Verordnung-Objekte) steht die Funktion medikationslisteAbrufen() (siehe Medikationsliste abrufen) zur Verfügung.
Eine Abfrage der Verordnungen aus einer ärztlichen Entlassung (in SS12 Format als Verordnung-Objekte) ist mittels der Funktion verordnungenAbrufen()) (siehe Verordnungen aus ärztlichem Entlassungsbrief abrufen) durchgeführt werden.
Für die Abfrage der Impfpass-Daten (in SS12 Format) stehen die Funktionen Impfpass abrufen und Immunisierungseinträge abrufen zur Verfügung.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung der Impf-Assertion (siehe Impf-Assertion)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I)
- Abfrage der e-Befunde mittels ITI-18 Transaktion
- Abfrage der Medikationsliste mittels PHARM-1-Transaktion
- Aufbereitung der retournierten Daten in vereinfachte SS12 Strukturen

### Dokumente abrufen

Die Funktion dokumenteAbrufen() ermöglicht den Abruf bestimmter Dokumente (e-Befunde, e-Medikations- oder e-Impfpass-Dokumente) im CDA-Format.
Die abzufragenden Dokumente sind mittels DokumentIds zu spezifizieren. Diese können den Metadaten der zuvor abgefragten Dokumentationsübersicht entnommen werden.
Sofern DokumentIds von e-Befunden oder e-Impfpass-Dokumenten angegebene werden, darf keine eMedId angegeben werden. Es muss in diesem Fall entweder eine SV-Nummer oder ein e-card Cardtoken angegeben werden (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken oder eMedId).
Hinweis: Dokumente der e-Medikation besitzen die homeCommunityid "1.2.40.0.34.3.9.107" und die repositoryId "1.2.40.0.34.6.7". Die Abfrage dieser Dokumente ist nur zulässig wenn der Benutzer das Recht ELGAAD.MEDIKATION besitzt.
Dokumente des e-Impfpasses besitzen die homeCommunityid "1.2.40.0.34.3.9.114". Die Abfrage dieser Dokumente ist nur zulässig wenn der Benutzer das Recht ELGAAD.IMPFPASS besitzt.
Befunde (Dokumente mit einer homeCommunityId ungleich der e-Medikation und ungleich des e-Impfpasses) können nur abgefragt werden wenn der Benutzer das Recht ELGAAD.BEFUND besitzt.
Es werden die CDA Dokumente in gezippter Form als MTOM Attachment (siehe hierzu auch Attachmenthandling) retourniert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I) bei Befunden und e-Impfpass-Dokumenten
- Ausstellung / Verwaltung der Impf-Assertion (siehe Impf-Assertion) bei e-Impfpass-Dokumenten
- Ausstellung / Verwaltung einer eMedId-Assertion (siehe eMedId und eMedId-Assertion) bei Angabe der eMedId
- Abfrage der Dokumente mittels entsprechender ITI-43-Transaktionen in Richtung Bereiche / e-Medikation / eImpfpass
- Aufbereitung der abgefragten CDA-Dokumente zum ZIP-Archiv

### Befund als PDF aufbereiten

Die Funktion befundPdfAufbereiten() ermöglicht den Abruf eines Befund mit Retournierung als aufbereitetes PDF.
Der abzufragende Befund ist mittels DokumentId zu spezifizieren. Dieser können den Metadaten der zuvor abgefragten Dokumentationsübersicht entnommen werden.
Hinweis: Dokumente der e-Medikation können mit dieser Funktion nicht abgefragt/aufbereitet werden. Diese Dokumente besitzen die homeCommunityid "1.2.40.0.34.3.9.107" und die repositoryId "1.2.40.0.34.6.7".
Es wird der ermittelte Befund als aufbereitetes PDF retourniert (siehe hierzu auch Attachmenthandling).
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I) oder
- Ausstellung / Verwaltung einer eMedId-Assertion (siehe eMedId und eMedId-Assertion)
- Abfrage des Befundes mittels ITI-43-Transaktionen
- Aufbereitung des Befundes (CDA) als PDF

### Medikationsliste abrufen

Die Funktion medikationslisteAbrufen() ermöglicht den Abruf der Medikationsliste in SS12 Objekt-Format.
Die Abfrage kann alleine mittels SV-Nummer/e-card CardToken (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken) oder mittels zusätzlicher Angabe der DokumentId der Medikationsliste durchgeführt werden. Diese kann den Metadaten der zuvor abgefragten Dokumentationsübersicht entnommen werden.
Hinweis: Wird keine DokumentId angegeben, erfolgt ein erneuter Aufruf zur Abfrage der Dokumentationsübersicht. Wird die DokumentId angegeben (bekannt durch einen zuvor erfolgten manuellen Aufruf zur Abfrage der Dokumentationsübersicht), erfolgt die sofortige Abfrage der Medikationsliste. Die DokumentId der e-Medikation enthält die homeCommunityId "1.2.40.0.34.3.9.107" und die repositoryId "1.2.40.0.34.6.7".
In diesem Fall (Angabe der DokumentId) reagiert die Funktion performanter.
Es wird die Medikationsliste in SS12 Objekt-Format retourniert. Abgaben ohne Verordnungsbezug werden dabei als Abgabe-Objekte, Abgaben mit Verordnungsbezug als Abgabe-Objekte innerhalb der zugehörigen Verordnung-Objekte zurückgeliefert. Verordnungen ohne (zugeordnete) Abgaben werden als Verordnung-Objekte retourniert.
Hinweis: Bei der Abfrage der Medikationsliste sind innerhalb der Abgaben und Verordnungen die Metadaten nur eingeschränkt befüllt. Die Metadaten enthalten in diesem Fall nur jeweils den Autor (Author) und das Erstelldatum (creationTime). Das Erstelldatum in den Metadaten ist in diesen Fällen immer ident zu dem Datum innerhalb von AuthorPerson. Für Verordnungen mit Abgaben (Abgaben mit Verordnungsbezug) gilt, dass innerhalb der Verordnung nur die (eingeschränkten) Metadaten, sowie die zugeh&oouml;rigen Abgaben enthalten sind. D.h. es werden in diesem Fall kein medizinischen Daten innerhalb der Verordnung, sondern nur noch in den tatsächlichen Abgaben geliefert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I)
- Abfrage der Dokumentenübersicht mittels entsprechender PHARM-1 Transaktion (nur wenn keine DokumentId angegeben wurde)
- Abfrage der Medikationsliste mittels ITI-43-Transaktion in Richtung e-Medikation
- Aufbereitung des abgefragten CDA-Dokuments als SS12 Objekte

### Verordnungen aus ärztlichem Entlassungsbrief abrufen

Die Funktion verordnungenAbrufen() extrahiert empfohlene Verordnungen aus einem ärztlichen Entlassungsbrief und retourniert sie in SS12 Objekt-Format. Es werden dabei nur strukturierte Verordnungen aus der empfohlenen Medikation extrahiert.
Die Abfrage kann mittels SV-Nummer/e-card CardToken (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken) durchgeführt werden.
Der ärztliche Entlassungsbrief muss mittels DokumentId angegeben werden. Diese kann den Metadaten der zuvor abgefragten Dokumentationsübersicht entnommen werden.
Eine Identifikation von ärztlichen Entlassungsbriefen innerhalb der retournierten Metadaten, kann mittels des Parameters Typecode erfolgen. Dieser beinhaltet bei ärztlichen Entlassungsbriefen ein Code-Objekt mit folgenden Wert aus dem ELGA-Value Set ELGA_Dokumentenklassen:
code - "11490-0", codeSystem - "2.16.840.1.113883.6.1"
Es werden die extrahierten Verordnungen in SS12 Format retourniert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I)
- Abfrage des Entlassungsbriefs mittel ITI-43-Transaktion in Richtung Bereich
- Verarbeitung des CDA Dokuments und Extrahierung der Verordnungen
- Aufbereitung der Verordnungen als SS12 Objekte

### Rezepte abrufen

Die Funktion rezepteAbrufen() ermöglicht den Abruf der Rezepte eines Patienten in SS12 Objekt-Format.
Per Boolschen Parameter kann angegeben werden, ob nur Rezepte retourniert werden sollen, für die noch Abgaben durchgeführt werden können.
Per Filterkriterien kann die Suche weiter eingeschränkt werden.
Die Abfrage kann mittels SV-Nummer/e-card CardToken oder eMedId (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card Cardtoken oder eMedId) durchgeführt werden.
Hinweis:

- Wird der Boolsche Parameter "fuerAbgabe" mit "false" angegeben, werden zusätzlich auch, zu den Suchkriterien passende, abgelaufenen Rezepte geliefert. Die Erkennung eines abgelaufenen Rezeptes erfolgt anhand des "availabilityStatus" innerhalb der Metadaten des Rezeptes. Ist dieser mit dem Wert "DEPRECATED" versorgt, handelt es sich, bei Lieferung der Rezepte innerhalb dieser Funktion, um ein abgelaufenes Rezept. Die Verordnungen innerhalb des abgelaufenen Rezeptes werden mit dem Verordnungsstatus "Offen" geliefert.
- Die Funktion retourniert keine Abgaben ohne Verordnungsbezug.

Es werden die gefundenen Rezepte in SS12 Objekt-Format retourniert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I) oder
- Ausstellung / Verwaltung einer eMedId-Assertion (siehe eMedId und eMedId-Assertion)
- Abfrage der Metadaten anhand der Suchkriterien mittels entsprechender PHARM-1 Transaktion
- Abfrage der CDA-Dokumente zur Rezeptaufbereitung mittels entsprechender ITI-43-Transaktionen
- Verarbeitung der CDA Dokumente und Konsolidierung der Daten
- Aufbereitung der Rezepte als SS12 Objekte

### Abgaben abrufen

Die Funktion abgabenAbrufen() ermöglicht die Abfrage von Abgaben eines Patienten in SS12 Objekt-Format.
Per Filterkriterien kann die Abfrage eingeschränkt werden.
Die Abfrage kann mittels SV-Nummer/e-card Cardtoken oder eMedId (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken oder eMedId) durchgeführt werden.
Es werden die gefundenen Daten in SS12 Objekt-Format retourniert. Abgaben ohne Verordnungsbezug werden dabei als Abgabe-Objekte, Abgaben mit Verordnungsbezug als Rezept-Objekte zurückgeliefert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I) oder
- Ausstellung / Verwaltung einer eMedId-Assertion (siehe eMedId und eMedId-Assertion)
- Abfrage der Metadaten anhand der Suchkriterien mittels entsprechender PHARM-1 Transaktion
- Abfrage der CDA-Dokumente mittels entsprechender ITI-43-Transaktionen
- Verarbeitung der CDA Dokumente und Konsolidierung der Daten
- Aufbereitung der Rezepte als SS12 Objekte

### Immunisierungseinträge abrufen

Die Funktion immunisierungseintraegeAbrufen() ermöglicht die Abfrage von bestimmten selbsterstellten Immunisierungseinträgen eines Patienten in SS12 Objekt-Format.
Per Filterkriterien kann die Abfrage auf einen bestimmten Zeitraum eingeschränkt werden.
Die Abfrage kann mittels SV-Nummer/e-card Cardtoken (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken) durchgeführt werden.
Es werden die gefundenen Daten in SS12 Objekt-Format retourniert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I) oder
- Ausstellung / Verwaltung der Impf-Assertion (siehe Impf-Assertion)
- Abfrage der Metadaten anhand der Suchkriterien mittels entsprechender PHARM-1 Transaktion
- Abfrage der CDA-Dokumente mittels entsprechender ITI-43-Transaktionen
- Verarbeitung der CDA Dokumente und Konsolidierung der Daten
- Aufbereitung der Rezepte als SS12 Objekte

### Impfpass als PDF aufbereiten

Die Funktion impfpassPdfAufbereiten() ermöglicht Abruf des Impfpasses mit Retournierung als aufbereitetes PDF..
Die Abfrage kann alleine mittels SV-Nummer/e-card CardToken (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken) oder mittels zusätzlicher Angabe der DokumentId des Impfpasses durchgeführt werden. Diese kann den Metadaten der zuvor abgefragten Dokumentationsübersicht entnommen werden.
Hinweis: Wird keine DokumentId angegeben, erfolgt ein erneuter Aufruf zur Abfrage der Dokumentationsübersicht. Wird die DokumentId angegeben (bekannt durch einen zuvor erfolgten manuellen Aufruf zur Abfrage der Dokumentationsübersicht), erfolgt die sofortige Abfrage des Impfpasses. Die DokumentId des Impfpasses enthält die homeCommunityId "1.2.40.0.34.3.9.114".
In diesem Fall (Angabe der DokumentId) reagiert die Funktion performanter.
Diese Funktion kapselt folgende Aktionen:
- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I) oder
- Ausstellung / Verwaltung der Impf-Assertion (siehe Impf-Assertion)
- Abfrage der Dokumentenübersicht mittels entsprechender PHARM-1 Transaktion (nur wenn keine DokumentId angegeben wurde)
- Abfrage des Impfpasses mittels ITI-43-Transaktionen
- Aufbereitung des Impfpasses (CDA) als PDF

## Kontaktbestätigungen verwalten

### Kontaktbestätigungen abrufen

Die Funktion kontaktbestaetigungenAbfragen() ermöglicht es dem GDA die Kontaktbestätigungen eines Patienen abzufragen bei denen er invloviert ist. Dadurch kann bereits vorab geprüft werden, ob bereits im KBS ein aktuell aktiver Kontakt vorhanden ist oder ob ein entsprechender Kontakt z.B. delegiert wurde.
Die Funktion kann mittels SV-Nummer/e-card CardToken (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken) durchgeführt werden.
Im Erfolgsfall werden die entsprechenden Kontaktbestätigungsdaten retourniert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)

Achtung:Durch Aufruf dieser Funktion wird keine neue Kontaktbestätigung ausgestellt!

### Patientenkontaktbestätigung erstellen

Die Funktion kontaktbestaetigungErstellen() ermöglicht es dem GDA zu gewährleisten, dass eine Kontaktbestätigung zu einem Patienten an das KBS gemeldet wurde beziehungsweise, dass falls notwendig eine Patientenkontaktbestätigung an das KBS gesendet wird.
Die Funktion kann mittels SV-Nummer/e-card CardToken (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken) durchgeführt werden. Im Erfolgsfall wird eine Bestätigung über den Kontakt retourniert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I)

### Zuweisungskontaktbestätigung erstellen

Die Funktion kontaktbestaetigungZuweisungErstellen() ermöglicht es dem GDA eine Zuweisungskontaktbestätigung an das KBS zu senden. Die Nutzung ist nur für GDAs mit der ELGA Rolle "Labor und Pathologie" zulässig.
Die Funktion kann nur mittels SV-Nummer durchgeführt werden. Wenn die e-card des Patienten vorhanden ist, ist eine Patientenkontaktbestätigung anstelle einer Zuweisungskontaktbestätigung auszustellen.
Zuweisungskontakte werden nicht im e-card System gespeichert und verwaltet!
Im Erfolgsfall wird eine Bestätigung retourniert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I)

## Ausstellen eines Rezeptes

### Medikamente suchen

Die Funktion medikamenteSuchen() ermöglicht die Abfrage von Medikamentendaten (aus der EMED-ASP-Liste) anhand verschiedener Suchparameter.
Es stehen folgende Suchkriterien zur Verfügung:

- Pharmazentralnummer - liefert bei erfolgreicher Suche immer genau ein Suchergebnis
- Handelsname - liefert bei erfolgreicher Suche ja nach Suchstring 1-n Suchergebnisse
  Hinweis: Der Suchstring ist kompatibel zu dem SQL Schlüsselwort LIKE, d.h. es gibt die Wildcards "%" für 0-n Zeichen und "_" für genau ein Zeichen.
  Bei der Suche nach Handelsname wird die Suche automatisch mit dem Wildcard "%" am Ende durchgeführt.
- Zulassungsnummer - liefert bei erfolgreicher Suche immer genau ein Suchergebnis

Es darf nur genau einer der drei Parameter angegeben werden.
Zusätzlich steht folgender Parameter für eine weitere Einschränkung des Suchergebnisses zur Verfügung:
Wechselwirkungsrelevant: Filterkriterium für die Wechselwirkungsrelevanz der mittels PZN/Zulassungsnummer/Handelsname gesuchten Arznei.
Hinweis: Der Parameter schränkt die Suche wie folgt ein:

- nicht angegeben oder mit dem Wert "false" versorgt:
  Es erfolgt eine Suche sowohl nach wechselwirkungsrelvanten, als auch nach nicht relevanten Arzneien (entsprechend der weiteren Suchkritieren PZN/Zulassungsnummer/Handelsname).
- mit dem Wert "true" versorgt:
  Es erfolgt nur Suche nach wechselwirkungsrelvanten Arzneien (entsprechend der weiteren Suchkritieren PZN/Zulassungsnummer/Handelsname).

### Wirkstoffe suchen

Die Funktion wirkstoffeSuchen() ermöglicht die Abfrage von Wirkstoffen (aus der ATC WIdO Liste) anhand verschiedener Suchparameter.
Es stehen folgende Suchkriterien zur Verfügung:

- Wirkstoffname - liefert bei erfolgreicher Suche ja nach Suchstring 1-n Suchergebnisse
  Hinweis: Der Suchstring ist kompatibel zu dem SQL Schlüsselwort LIKE, d.h. es gibt die Wildcards "%" für 0-n Zeichen und "_" für genau ein Zeichen.
  Bei der Suche nach Wirkstoffname wird die Suche automatisch mit dem Wildcard "%" am Ende durchgeführt.
- ATC-Code - liefert bei erfolgreicher Suche ja nach Suchstring 1-n Suchergebnisse
  Hinweis: Der Suchstring ist kompatibel zu dem SQL Schlüsselwort LIKE, d.h. es gibt die Wildcards "%" für 0-n Zeichen und "_" für genau ein Zeichen.

Es darf nur genau einer der beiden Parameter angegeben werden.

### eMedId erstellen

Die Funktion emedIdErstellen() ermöglicht die Abfrage einer eMedId von e-Medikation. Diese eMedId kann anschließend als Parameter an die Funktion rezeptAusstellen() übergeben werden.
Die Funktion kann mittels optional mittels SV-Nummer/e-card CardToken (siehe auch Funktionen mit optionaler Angabe SV-Nummer/e-card CardToken) durchgeführt werden.
Hinweis: In diesem Fall wird die SV-Nummer in e-Medikation mit der eMedId verknüpft. Wird die eMedId zur Ausstellung eines Rezeptes verwendet, muss die dort verwendete SV-Nummer ident zur SV-Nummer der eMedId Erstellung sein.
Mittels des Parameters isDataMatrixRequired kann angegeben werden, ob zusätzlich zur eMedId auch der Datamatrix-Code retourniert werden soll.
Im Erfolgsfall wird die erstellte eMedId, sowie falls gewünscht der aufbereitete DataMatrix-Code retourniert (die Retournierung erfolgt als MTOM-Attachment - siehe hierzu auch Attachmenthandling).
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Anfordern einer eMedId
- Aufbereitung der Rückgabedaten als SS12 Objekt / MTOM-Attachment

### Rezept ausstellen

Die Funktion rezeptAusstellen() speichert ein Rezept in der e-Medikation für einen ELGA-Teilnehmer.
Die Funktion kann mittels SV-Nummer/e-card CardToken unter optionaler Angabe einer erstellten eMedid (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken und optionaler eMedId Angabe) durchgeführt werden.
Wird in den Metadaten kein Author angegeben, werden für die Organisationsdaten die GDA-Namens- und Ordinationsdaten aus dem e-card System herangezogen. Die Daten werden anhand der Vertragspartnernummer des angemeldeten Dialogs ermittelt. Die Personendaten des Authors werden anhand der angegebenen ELGA-Daten beim Dialogaufbau automatisch befüllt. Hierzu müssen beim Dialogaufbau die GDAMA-Daten angegeben worden sein, anderenfalls ist eine automatische Befüllung nicht möglich und es wird mit einem Fehler des e-card Systems abgebrochen. Eine Ausstellung ist in diesem Fall nur möglich unter expliziter Angabe des Namens des Authors (da keine automatische Befüllung stattfinden kann).
Wird der Patient nicht bei der Erfassung ausspezifiziert, werden die Namensdaten, sowie das Geschlecht und das Geburtsdatum aus dem e-card System verwendet.
Für die ClinicalDokument-Id wird die erstellte eMedId verwendet. Das Rezept wird immer automatisch mit confidentialityCode N (normal) erstellt.
Parameter die bei der Erstellung nicht anzugeben sind (z.B. confidentialityCode in den Metadaten), siehe hierzu die Objektbeschreibungen in der Javadoc, werden in der weiteren Verarbeitung ignoriert!
Es werden, zusätzlich zum gespeicherten Rezept im SS12 Objekt-Format, der erstellten DataMatrix-Code (als MTOM-Attachment - siehe hierzu auch Attachmenthandling) retourniert. Es wird nur ein DataMatrix-Code retourniertm wenn in den Eingangsdaten der Funktion die eMedId nicht als Parameter übergeben wurde.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I)
- Anfordern einer eMedId für das Rezept (sofern die eMedId nicht als Parameter übergeben wurde, siehe auch eMedId und eMedId-Assertion)
- Aufbereitung des Rezeptes als CDA-Dokument inkl. Header und Metadaten
- Speichern des Rezeptes in e-Medikation mittels ITI-41-Transaktion
- Verarbeitung des von e-Medikation retournierten CDA Dokuments
- Aufbereitung der Rückgabedaten als SS12 Objekt / MTOM-Attachment

## Abgaben speichern

Die Funktion abgabenSpeichern() speichert für einen ELGA-Teilnehmer Abgaben in der e-Medikation.
Die Funktion kann mittels SV-Nummer/e-card CardToken oder eMedId (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken oder eMedId) durchgeführt werden.
Hinweis: Sofern die eMedId bekannt ist (DataMatrix-Code, eMedId am Rezept, Abfrage der Rezepte für den Patienten), kann die Abgabe zum Rezept erfasst werden. Andernfalls erfolgt die Speicherung ohne Rezeptbezug (z.B. benötigt zur Erfassung der Abgabe von OTCs die ohne Rezept abgegeben werden).
Es können 1-n Abgaben gleichzeitig angegeben werden. Es kann jedoch nur eine eMedId angegeben werden. D.h. bei Einlösung mehrerer Rezepte, sind mehrere Requests zu senden.
Bzgl. der Defaultbefüllungen innerhalb der Metadaten (Author, Patient, ...) gelten dieselben Bedingungen wie bei der Funktion Rezept ausstellen.
Es werden die gespeicherten Abgaben in SS12 Objekt-Format retourniert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I) oder
- Ausstellung / Verwaltung einer eMedId-Assertion (siehe eMedId und eMedId-Assertion)
- Anfordern der eMedIds für die einzelnen Abgaben (siehe eMedId und eMedId-Assertion)
- Aufbereitung der Abgaben als CDA-Dokumente inkl. Header und Metadaten
- Speichern des einzelnen Abgaben in e-Medikation mittels ITI-41-Transaktionen
- Verarbeitung der von e-Medikation retournierten CDA Dokumente
- Aufbereitung der Rückgabedaten als SS12 Objekte

## Impfpass / Impfungen speichern

### Impfstoffe suchen

Die Funktion impfstoffeSuchen() ermöglicht die Abfrage von Impfstoffen (aus den Listen eImpf_Impfstoffe und eImpf_HistorischeImpfstoffe) anhand verschiedener Suchparameter.
Es stehen folgende Suchkriterien zur Verfügung:

- Pharmazentralnummer - liefert bei erfolgreicher Suche immer genau ein Suchergebnis
- Handelsname - liefert bei erfolgreicher Suche ja nach Suchstring 1-n Suchergebnisse
  Hinweis: Der Suchstring ist kompatibel zu dem SQL Schlüsselwort LIKE, d.h. es gibt die Wildcards "%" für 0-n Zeichen und "_" für genau ein Zeichen.
  Bei der Suche nach Handelsname wird die Suche automatisch mit dem Wildcard "%" am Ende durchgeführt.

Es darf nur genau einer der beiden Parameter angegeben werden.

### Immunierungseinträge speichern

Die Funktion immunisierungseintraegeSpeichern() speichert einen Immunisierungseintrag für einen Patienten im e-Impfpass. Im e-card System ist beim Erfassen nur die Angabe genau eines Immunisierungseintrags innerhalb der Funktion zulässig. Innerhalb des Immunisierungseintrags darf nur genau eine Impfung für die Speicherung angegeben werden.
Die Erfassung einer Impfung ist für aktuelle/selbsterfasste, sowie auch für die Nachtragung von älteren /fremderfassten Impfungen möglich. Zusätzlich zu Impfungen können mit dieser Funktion unter andern auch impfrelevante Erkrankungen, sowie Antikörperbestimmungen erfasst werden (siehe hierzu auch die entsprechende Dokumentation unter www.elga.gv.at).
Die Funktion kann mittels SV-Nummer/e-card CardToken (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken) durchgeführt werden.
Wird in den Metadaten kein Author angegeben, werden für die Organisationsdaten die GDA-Namens- und Ordinationsdaten aus dem e-card System herangezogen. Die Daten werden anhand der Vertragspartnernummer des angemeldeten Dialogs ermittelt. Die Personendaten des Authors werden anhand der angegebenen ELGA-Daten beim Dialogaufbau automatisch befüllt. Hierzu müssen beim Dialogaufbau die GDAMA-Daten angegeben worden sein, anderenfalls ist eine automatische Befüllung nicht möglich und es wird mit einem Fehler des e-card Systems abgebrochen. Eine Ausstellung ist in diesem Fall nur möglich unter expliziter Angabe des Namens des Authors (da keine automatische Befüllung stattfinden kann).
Wird der Patient nicht bei der Erfassung ausspezifiziert, werden die Namensdaten, sowie das Geschlecht und das Geburtsdatum aus dem e-card System verwendet.
Parameter die bei der Erstellung nicht anzugeben sind (z.B. confidentialityCode in den Metadaten), siehe hierzu die Objektbeschreibungen in der Javadoc, werden in der weiteren Verarbeitung ignoriert!
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I)
- Ausstellung / Verwaltung der Impf-Assertion (siehe Impf-Assertion)
- Aufbereitung der Immunisierungseinträge als CDA-Dokument inkl. Header und Metadaten
- Speichern der Daten in e-Impfpass mittels ITI-41-Transaktion
- Verarbeitung der von e-Impfpass retournierten CDA Dokumente
- Aufbereitung der Rückgabedaten

## Korrekturfälle

### Verordnungen ändern

Die Funktion verordnungenAendern() ermöglicht es, mehrere Verordnungen zu ändern oder zu stornieren (Status "storniert").
Die Funktion kann mittels SV-Nummer/e-card CardToken (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken) durchgeführt werden.
Es können 1-n Änderungsobjekte (AbgabeVerordnungAenderung) gleichzeitig angegeben werden. Es können jedoch nur einmal Metadaten angegeben werden. D.h. bei es ist beim Ändern/Stornieren von mehreren Verordnungen darauf zu achten, diese entsprechend der Metadaten zu sortieren und im Bedarf auf mehrere Requests aufzuteilen.
Bzgl. der Defaultbefüllungen innerhalb der Metadaten (Author, Patient, ...) gelten dieselben Bedingungen wie bei der Funktion Rezept ausstellen.
Das Objekt AbgabeVerordnungAenderung enthält nur für die Änderung relevante Daten. Es ist dabei zu beachten, dass die enthaltene Felder die nicht ge&aum;ndert werden sollen, mit den zuvor gütigen Werten anzugeben sind.
Zum Stornieren der Verordnung ist der Parameter Storniert in der Verordnung mit true zu befüllen. Bei einer Änderung der Verordnungsdaten (z.B. der Dosierung) ist der Parameter Storniert mit false anzugeben. Eine Änderung ist nur möglich, solange die Verordnung noch offen ist.
Es wird eine Map von VerordnungsIds zu den DokumentIds der dafür erzeugten Pharmazeutischen Empfehlungen retourniert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I)
- Abfrage der Metadaten der Verordnungen mittels entsprechender PHARM-1 Transaktionen
- Abfrage der zugehörigen CDA-Dokumente mittels entsprechender ITI-43-Transaktionen
- Verarbeitung der CDA Dokumente und Konsolidierung der Daten
- Anfordern der eMedIds für die Verordnungen (siehe eMedId und eMedId-Assertion)
- Aufbereitung der zu ändernden Verordnungen als CDA-Dokument (PADV-Dokument) inkl. Header und Metadaten anhand der Änderungsangaben und den ermittelten Daten
- Speichern der Änderung in e-Medikation mittels ITI-41-Transaktion
- Verarbeitung der von e-Medikation retournierten CDA Dokumente
- Aufbereitung der Rückgabedaten

### Abgabe ändern

Die Funktion abgabeAendern() ermöglicht es, eine Abgabe zu ändern oder abzusetzen.
Die Funktion kann mittels SV-Nummer/e-card CardToken oder eMedId (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken oder eMedId) durchgeführt werden.
Hinweis: Sofern die eMedId bekannt ist, kann die Abgabeänderung zum Rezept erfasst werden.
Es kann nur zu genau eine Abgabe mittels des Änderungsobjekte (AbgabeVerordnungAenderung) geändert werden.
Das Objekt AbgabeVerordnungAenderung enthält nur für die Änderung relevante Daten. Es ist dabei zu beachten, dass die enthaltene Felder die nicht ge&aum;ndert werden sollen, mit den zuvor gütigen Werten anzugeben sind.
Bzgl. der Defaultbefüllungen innerhalb der Metadaten (Author, Patient, ...) gelten dieselben Bedingungen wie bei der Funktion Rezept ausstellen.
Zum Absetzen der Abgabe ist der Parameter Storniert in AbgabeVerordnungAenderung mit true zu befüllen. Bei einer Änderung der Abgabedaten (z.B. abgegebene Packungsanzahl) ist der Parameter Storniert mit false anzugeben.
Es wird eine ÄnderungsId der für die Abgabe erzeugten Pharmazeutischen Empfehlung retourniert.
Hinweis: Um das zugehörige Dokument mittels der Funktion dokumenteAbrufen() (siehe Dokumente abrufen) ist die DokumentId wie folgt zu befüllen:

- uniqueId - retournierte ÄnderungsId der Funktion abgabeAendern()
- entryUUID - bleibt leer
- homeCommunityId - fixer Wert für e-Medikation -> "1.2.40.0.34.3.9.107"
- repositoryId - fixer Wert für e-Medikation -> "1.2.40.0.34.6.7"

Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I) oder
- Ausstellung / Verwaltung einer eMedId-Assertion (siehe eMedId und eMedId-Assertion)
- Abfrage der Metadaten der Abgabe anhand der Suchkriterien mittels entsprechender PHARM-1 Transaktion
- Abfrage des CDA-Dokuments der Abgabe mittels entsprechender ITI-43-Transaktionen
- Anfordern der eMedId für die Abgabe (siehe eMedId und eMedId-Assertion)
- Aufbereitung der zu ändernden Abgabe anhand der Änderungsdaten und den abgefragten Daten als CDA-Dokument (PADV-Dokument) inkl. Header und Metadaten
- Speichern der Änderung in e-Medikation mittels ITI-41-Transaktion
- Verarbeitung der von e-Medikation retournierten Daten
- Aufbereitung der Rückgabedaten

### Dokumente aus der e-Medikation stornieren

Die Funktion dokumenteStornieren() dient dem Stornieren von Dokumenten der e-Medikation. Durch die Stornierung wird der Dokumentenstatus von APPROVED auf DEPRECATED gesetzt.
Die Funktion kann mittels SV-Nummer/e-card CardToken oder eMedId (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken oder eMedId) durchgeführt werden.
Hinweis: Sofern die eMedId bekannt ist, kann die Stornierung mit Bezug auf das Rezept durchgeführt werden. Dabei gilt, dass bei einem Kassen- bzw. Substitutionsrezept alle Abgaben zu diesem Rezept storniert werden müssen! Nach Stornierung aller Abgaben, erhält das Rezept den Status OFFEN und kann wieder abgegeben werden.
Wird die mittels der Funktion verordnungenAendern() (siehe Verordnungen ändern) durchgeführte Änderung auf den Status Storniert mittels dieser Funktion (Dokumente stornieren) storniert, erhält die Verordnung den Status OFFEN.
Wird die mittels der Funktion abgabeAendern() (siehe Abgabe ändern) gespeicherte Absetzung einer Abgabe mittels dieser Funktion (Dokument stornieren) storniert, erhält die Abgabe den Status ABGEGEBEN.
Es können mehrere Dokumente auf einmal angegeben werden. Ein Dokument muss mittels der entryUUID spezifiziert werden. Die entryUUID ist jeweils in den Metadaten zu finden unter:

Metadaten -> id (vom Typ dokumentId) -> entryuuid

Bei erfolgreicher Durchführung kommt als Ergebnis eine leere Response zurück.
Bzgl. der Defaultbefüllungen innerhalb der Metadaten (Author, Patient, ...) gelten dieselben Bedingungen wie bei der Funktion Rezept ausstellen.
Die Stornierung ist nur innerhalb eines (in Stunden definierten) Zeitraums durch den Ersteller des Dokuments möglich!
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I) oder
- Ausstellung / Verwaltung einer eMedId-Assertion (siehe eMedId und eMedId-Assertion)
- Stornierung der Dokumente in e-Medikation mittels ITI-57-Transaktion

### Immunisierungseinträge aktualisieren

Die Funktion immunisierungseintraegeAktualisieren() ermöglicht es, mehrere Immunisieurngseinträge zu ändern.
Die Änderung ist nur zulässig, wenn dadurch keine inkonsistenten Datenbestände entstehen. Es ist z.B. nicht möglich Informationen zu löschen, auf denen spätere Impfeinträge beruhen.
Die Funktion kann mittels SV-Nummer/e-card CardToken (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken) durchgeführt werden.
Es können 1-n Immunisierungseinträge gleichzeitig angegeben werden.
Im Gegensatz zur e-Medikation bei der nur einmal Metadaten angegeben werden, enthält beim e-Impfpass jeder einzelne Eintrag eigene Metadaten. In den Metadaten ist die Referenz auf das zu ändernde Dokument zu setzen.
Zusätzlich zu Impfungen können mit dieser Funktion unter andern auch impfrelevante Erkrankungen, sowie Antikörperbestimmungen aktualisiert werden (siehe hierzu auch die entsprechende Dokumentation unter www.elga.gv.at).
Bzgl. der Defaultbefüllungen innerhalb der Metadaten (Author, Patient, ...) gelten dieselben Bedingungen wie bei der Funktion Immunierungseinträge speichern.
Durch eine Änderung wird die Vorversion des Dokuments auf "DEPRECATED" gesetzt und die neue (gemeldete) Version mit dem Status "APPROVED" gekennzeichnet.
Bei der Änderung sind alle gewünschten Daten des neuen (geänderten) Immunisierungseintrags anzugeben. Es erfolgt kein Mergen von alten und neuen Daten durch den ELGA-Adapter. Daten die in der neuen Version des Dokuments nicht enthalten sind, gelten als gelöscht.
Das Löschen aller Einträge innerhalb eines Immunisierungseintrags ist nicht zulässig. Zur Löschung aller Daten ist die Funktionaltität des Stornieren eines Immunisierungseintrags zu verwenden.
Als Ergebnis werden die neuen Versionen der Immunisierungseinträge retourniert.
Die Berechtigung für eine Korrektur von bereits eingetragenen Immunisierungseinträgen hat in der Regel nur jener GDA, der diese Impfdaten eingetragen hat.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I)
- Ausstellung / Verwaltung der Impf-Assertion (siehe Impf-Assertion)
- Aufbereitung der zu ändernden Immunisierungseinträge als CDA-Dokument inkl. Header und Metadaten anhand der Änderungsangaben
- Speichern der Änderung in e-Impfpass mittels ITI-41-Transaktion
- Verarbeitung der von e-Impfpass retournierten CDA Dokumente
- Aufbereitung der Rückgabedaten

### Immunisierungseinträge stornieren

Die Funktion immunisierungseintraegeStornieren() dient dem Stornieren von einzelen Immunisierungseinträgen des e-Impfpasses. Durch die Stornierung wird der Dokumentenstatus des jeweiligen Immunisierungseintrags von APPROVED auf DEPRECATED gesetzt.
Die Stornierung ist nur zulässig, wenn dadurch keine inkonsistenten Datenbestände entstehen. Es ist z.B. nicht möglich Informationen zu stornieren, auf denen spätere Impfeinträge beruhen.
Die Funktion kann mittels SV-Nummer/e-card CardToken (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken) durchgeführt werden.
Es ist zu beachten, dass durch das Stornieren eines Immunisierungseintrags alle Daten innerhalb des Immunisierungseintrags storniert werden. Bei nativ Implementierung und Angabe mehrerer Impfungen innerhalb eines Immunisierungseintrags ist daher in Abhängigkeit davon ob alle oder nur einzelne Informationen innerhalb der Immunisierungseintrags storniert werden sollen entweder die Funktionaltität zum Stornieren (alle Informationen) oder die der Aktualisierung (es werden nur bestimmte Informationen gelöscht/geändert) zu verwenden.
Bei Erfassung eines Immunisierungseintrags über das eCS (GUI und SS12) ist immer nur die Angabe genau einer Impfung möglich. Es wird bei nativ Implementierung empfohlen ebenfalls nur genau eine Impfung pro Immunisieurngseintrag zu speichern.
Es können mehrere Dokumente auf einmal angegeben werden. Ein Dokument muss mittels der entryUUID spezifiziert werden. Die entryUUID ist jeweils in den Metadaten zu finden unter:

Metadaten -> id (vom Typ dokumentId) -> entryuuid

Bei erfolgreicher Durchführung kommt als Ergebnis eine leere Response zurück.
Bzgl. der Defaultbefüllungen innerhalb der Metadaten (Author, Patient, ...) gelten dieselben Bedingungen wie bei der Funktion Immunierungseinträge speichern.
Die Berechtigung für eine Stornierung von bereits eingetragenen Immunisierungseinträgen hat in der Regel nur jener GDA, der diese Impfdaten eingetragen hat.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I) oder
- Ausstellung / Verwaltung der Impf-Assertion (siehe Impf-Assertion)
- Stornierung der Immunisierungseinträge in e-Impfpass mittels ITI-57-Transaktion

## Patientenkontakt delegieren

### GDA mittels VPNR suchen

Die Funktion gdaVpnrSuche() ermöglicht die Abfrage von GDA-Daten mittels VPNR aus dem GDA-I.
Im Erfolgsfall werden die ermittelten GDA-Daten als GdaDeskriptor-Objekt retourniert.
Der GdaDeskriptor enthät in diesem Fall (nur) die VPNR mit der die Abfrage durchgeführt wurde, auch wenn zum GDA unter Umständen mehrere VPNRs im GDA-I bekannt sind!
Diese Funktion kapselt folgende Aktionen:

- Abfrage des GDA-I
- Aufbereitung der Rückgabedaten als SS12 Objekt

### GDA mittels Kriterien suchen

Die Funktion gdaKriterienSuche ermöglicht die Suche von GDA-Daten mittels Suchkriterien aus dem GDA-I.
Als Selektionskriterien stehen folgende Parameter zur Auswahl:

- GdaName
  Der Name ist verpflichtend als Suchkriterium anzugeben.
  Hinweis: Es kann "%" als Wildcard verwendet werden, wobei dies nur am Anfang oder am Ende des Suchstrings zulässig ist und der restliche Suchstirng mindesten 2 Buchstaben lang sein muss.
- ElgaRolle
  Optionaler weiterer Suchparameter zur Einschränkung.
- Plz
  Optionaler weiterer Suchparameter zur Einschränkung.

Die Suchkriterien werden dabei additiv verwendet.
Im Erfolgsfall werden die ermittelten GDA-Daten als GdaDeskriptor-Objekte retourniert.
Der GdaDeskriptor enthät in diesem Fall alle VPNRs die GDA im GDA-I bekannt sind!
Diese Funktion kapselt folgende Aktionen:

- Abfrage des GDA-I
- Aufbereitung der Rückgabedaten als SS12 Objekte

### GDAs mittels OIDs suchen

Die Funktion gdasOidsSuche ermöglicht die Suche von mehreren GDA-Daten mittels der GDA-OIDs aus dem GDA-I.
Im Erfolgsfall werden zu den ermittelten GDAs die Daten als GdaDeskriptor-Objekte retourniert.
Diese Funktion kapselt folgende Aktionen:

- Abfrage des GDA-I
- Aufbereitung der Rückgabedaten als SS12 Objekte

### Kontaktbestätigung delegieren

Die Funktion kontaktbestaetigungDelegieren() ermöglicht es dem Vertragspartner, seinen Kontakt mit einem Patienten an einen anderen GDA zu delegieren, der Zugriff auf die ELGA-Daten des Patienten benötigt.
Die Funktion kann mittels SV-Nummer/e-card CardToken (siehe auch Funktionen mit zwingender Angabe SV-Nummer/e-card CardToken) durchgeführt werden.
Der GDA an den der Kontakt delegiert werden soll, ist mittels GdaId anzugeben.
Die GdaId ist im GdaDeskriptor an folgender Stelle zu finden:

- GdaDeskriptor -> GdaId (vom Typ InstanceIdentifier) -> InstanceIdentifierBase -> Id

Bei erfolgreicher Durchführung wird die ID der delegierten Kontaktbestätigung retourniert.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)
- Ausstellung / Verwaltung einer Kontaktbestätigung (siehe Kontaktbestätigungen und ZP-I)
- Weiterleitung der Delegierung ans Kontaktbestätigungsservice (KBS)

## Protokolldaten abrufen

Die Funktion protokolldatenAbrufen() ermöglicht die Abfrage der Protokolldaten (siehe hierzu auch Protokollierung der Funktionsaufrufe).
Im Erfolgsfall werden die ermittelten Protokolleinträge retourniert.
Die Retournierung der Protokolleinträge ist begrenzt, daher wird zusätzlich zu den Protokolleinträgen die Anzahl der zu den Kriterien ermitteln Einträge retourniert. Unterscheidet sich diese Anzahl von der Anzahl an gelieferten Protokolleinträgen ist zur Abfrage der weiteren Protokolleinträge ein weiterer Funktionsaufruf mit spezifischeren Suchkriteren durchzuführen.

## Assertion abrufen

### HCP-Assertion abrufen

Die Funktion hcpAssertionAbrufen() ermöglicht die Abfrage einer HCP-Assertion (siehe Kapitel Authentifizierung und GDA-I) mittels der Dialog-ID.
Im Erfolgsfall wird eine HCP-Assertion retourniert, entweder eine die zuvor ausgestellt und gültig ist oder eine neu erstellte.
Diese Funktion kapselt folgende Aktionen:

- Ausstellung / Verwaltung der Authentifizierungsbestätigung (siehe Authentifizierung und GDA-I)