Die Beschreibung der Ein-und Ausgangsparameter der Funktionen sind der
in der ELGAAD Javadoc zu entnehmen.
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:
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 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:
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:
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:
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
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
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:
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:
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: