Kontaktbestätigungen¶

Aufgabe des Kontaktbestätigung Services (KBS) ist die Speicherung eines Nachweises mit Zeitstempel eines Behandlungskontaktes zwischen einem Gesundheitsdienstanbieter (GDA) und einem Patienten. Der Patient steht in unmittelbarer Behandlung mit diesem GDA, in welcher Rolle auch immer der GDA gerade arbeitet. Ein Kontakt eines GDA mit einem Patienten ist somit kontextfrei. Folglich ist der Kontakt bei einem Zugriff, unabhängig in welchem Kontext er erfasst wurde, gültig.

Die im KBS persistierten Kontakte sind rollenfrei, wobei der Zugriff auf Dokumente (lesend / schreibend) von der jeweiligen ELGA / e-Health-Rolle abhängig ist. Der Zugriff auf die ELGA / e-Health Anwendung ist weiters von den jeweiligen anwendungsspezifischen Permissions abhängig. Der Amtsarzt, der den Patienten soeben geimpft hat, und daher im KBS mit dem Patienten einen Behandlungskontakt hat, kann in der Rolle Amtsarzt und der e-Impfpass Kontext-Assertion nicht auf dessen ELGA zugreifen. Der Primärversorgungs-GDA in der Rolle ELGA-GDA, kann ein und denselben Kontakt sowohl für den Zugriff im PVN, als auch auf die ELGA nutzen. Der Zugriff wird hier über die jeweilige Rolle und der daraus resultierenden Kontext-Assertion abgeleitet.

In den folgenden Tabellen werden die ELGA / e-Health-Rollen und deren Berechtigungen zur Einmeldung einer Kontaktbestätigung mittels der jeweiligen ELGA / e-Health-Assertion definiert. Die in den Tabellen definierten Berechtigungen beziehen sich nicht auf die Erlaubnis eine Kontext-Assertion zu lösen.

Das grundsätzlich hinterlegte Regelset des Subsequent Type Handling von Kontaktbestätigungen verhält sich weiterhin ident zu dem im Kontext von ELGA etablierten Type Handling.

Beim Einbringen der Kontaktbestätigungen mit einer e-Impfpass Kontext-Assertion (entsprechend Berechtigungsmatrix) gelten die im nachfolgenden Abschnitt gelisteten Richtlinien.

Es können analog zu ELGA, Kontaktbestätigungen auch mit einer e-Impfpass Kontext-Assertion eingebracht werden. Hierfür muss die e-Impfpass Kontext-Assertion im SOAP Security Header, anstelle der HCP-Assertion, mitgeführt werden.

Es stehen die ELGA Standard Funktionen "5.1.2.3 Registrieren einer Kontaktbestätigung", "5.1.2.5 Delegieren einer Kontaktbestätigung" und "5.1.2.6 Stornieren einer Kontaktbestätigung" aus dem allgemeinen BeS Schnittstellendokument zur Verfügung.

KBS Berechtigungsmatrix – e-Impfpass Kontext-Assertion (Anwendung 103 e-Impfpass)¶

e-Health Rolle (e-Impfpass)	Code	Kontakte(e) abfragen
GDA Arzt	700
GDA Zahnarzt	701	Im Rahmen des e-Impfpasses nicht vorgesehen
GDA Apotheke	704
GDA KH	702
GDA PH	703
Bürger	610
Amtsarzt	716
Korrektur-berechtigter	717
Krisenmanager	718
Arbeits- medizin	721
GDA Hebamme	722
Labor und Pathologie	724
Gesundheitsberatung 1450	729

Tabelle: KBS Sendeverhalten e-Impfpass

	Zugriff bzw. keine Einschränkung
	Kontakteinbringung nur mittels PIM105 möglich
	Kein Zugriff

Für alle folgenden Use Cases gilt, dass auch Kontakte abgefragt werden dürfen.

Use Case GDA Arzt¶

GDA in der ELGA-Rolle (niedergelassener) Arzt (700) dürfen nur ambulante Kontakte melden, delegieren und stornieren. Zulässige Qualitäten (bezogen auf die Kontaktbestätigungen) der Patientenidentifikation sind ausschließlich die Nutzung des e-card Systems mit Stecken der e-card sowie die Verwendung der mobilen e-Impfpass Datenerfassung. Der Kontakt kann somit über die Identifizierungsmethode PIM105, PIM106 und über das e-card spezifische KBS (PIM101) eingebracht werden. Weitere Details zu PIM105 siehe Kapitel Identifizierungsmethode PIM105.

Use Case GDA Zahnarzt¶

Im Rahmen des e-Impfpasses (Rolle 701) nicht vorgesehen, ansonsten analog zu ELGA. Die Anforderung einer e-Impfpass Kontext-Assertion ist nicht erlaubt.

Use Case GDA Apotheke¶

GDA in der ELGA-Rolle Apotheke (704) dürfen nur über einen gültigen ambulanten Kontakt (diese werden explizit mittels einer HCP-Assertion eingebracht) auf den e-Impfpass zugreifen. Zulässige Qualität (bezogen auf die Kontaktbestätigungen) der Patientenidentifikation ist ausschließlich die Nutzung des e-card Systems mit Stecken der e-card.

Use Case GDA KH und PH¶

GDA in der ELGA-Rolle Krankenhaus bzw. Krankenanstalt/Ambulatorium oder Pflegeeinrichtung (702 und 703) dürfen sowohl ambulante wie auch stationäre Kontakte melden, delegieren und stornieren. Zulässige Qualitäten (bezogen auf die Kontaktbestätigungen) der Patientenidentifikation sind die Nutzung des L-PI, des e-card Systems mit und ohne Stecken der e-card sowie das Stecken der Bürgerkarte. Von Rolle 702 können weiters Kontakte mit PIM106 (nicht möglich über 703) eingebracht werden.

Use Case Bürger / Vertreter¶

Der Bürger bzw. dessen Vertreter kann via EBP (im Rahmen von ELGA) volle Einsicht in die Liste der Behandlungszusammenhänge, welche im KBS zu seiner Identität persistiert wurden, nehmen. Dies ist jedoch nur mittels User bzw. Mandate I-Assertion möglich und nicht mit der e-Impfpass Kontext-Assertion.

Use Case Amtsarzt¶

GDA in der e-Health-Rolle Amtsarzt (716) dürfen sowohl ambulante wie auch stationäre Kontakte melden, delegieren und stornieren. Zulässige Qualitäten (bezogen auf die Kontaktbestätigungen) der Patientenidentifikation sind die Nutzung des Z-PI, sowie das Stecken der Bürgerkarte. Hierfür muss eine dem Z-PI bekannte Patientenidentifikation verwendet werden.

Das Melden eines stationären Kontaktes wird erforderlich, wenn z.B. bei Ebola-Verdacht den Patienten von der in Schutzanzügen ausgerüsteten Exekutive in Isolation verlegt wird.

Use Case Korrekturberechtigter¶

GDA in der e-Health-Rolle Korrekturberechtigter (717) dürfen nur ambulante Kontakte melden, delegieren und stornieren. Zulässige Qualitäten (bezogen auf die Kontaktbestätigungen) der Patientenidentifikation sind die Nutzung des Z-PI, sowie das Stecken der Bürgerkarte. Hierfür muss eine dem Z-PI bekannte Patientenidentifikation verwendet werden.

Use Case Krisenmanager¶

GDA in der e-Health-Rolle Krisenmanager (718) dürfen keinen Kontakt einbringen. Für den Zugriff ist kein Kontakt erforderlich.

Use Case Arbeitsmedizin¶

GDA in der ELGA-Rolle Arbeitsmedizin (721) dürfen ausschließlich ambulante Kontakte melden, delegieren und stornieren. Einmeldung von Kontakten mit Identifizierungsmethode PIM105 erlaubt. Ebenso wird eine Kontaktabfrage ermöglicht. Zulässige Qualitäten (bezogen auf die Kontaktbestätigungen) der Patientenidentifikation sind die Nutzung des Z-PI, des e-card Systems mit und ohne Stecken der e-card sowie das Stecken der Bürgerkarte. Hierfür muss eine dem Z-PI bekannte Patientenidentifikation verwendet werden.

Use Case GDA Hebamme¶

GDA in der e-Health-Rolle Hebamme (722) dürfen ausschließlich ambulante Kontakte einbringen, abfragen, stornieren und delegieren.

Zulässige Qualitäten (bezogen auf die Kontaktbestätigungen) der Patientenidentifikation sind die Nutzung des Z-PI, mit und ohne Stecken der e-card, das Stecken der Bürgerkarte (genannte Qualitäten über Anbindung an ELGA-Bereich), sowie die Verwendung der mobilen e-Impfpass Anwendung (über eHealth-Internetgateway für e-Impfpass).

Use Case Labor und Pathologie¶

GDA in der e-Health-Rolle Labor und Pathologie (724) dürfen nur ambulante Kontakte melden, delegieren und stornieren.

Zulässige Qualitäten (bezogen auf die Kontaktbestätigungen) der Patientenidentifikation sind ausschließlich die Nutzung des e-card Systems mit Stecken der e-card, sowie die Verwendung der mobilen e-Impfpass Anwendung. Der Kontakt kann somit über die Identifizierungsmethode PIM105, PIM106 und über das e-card spezifische KBS (PIM101) eingebracht werden.

Use Case Gesundheitsberatung 1450¶

GDA in der ELGA-Rolle Gesundheitsberatung 1450 (729) darf nur Internetkontakte melden, delegieren und stornieren. Zulässige Qualitäten (bezogen auf die Kontaktbestätigungen) der Patientenidentifikation sind die Nutzung von ID Austria sowie die Identifikation anhand amtlichen Lichtbildausweis. Hierfür muss eine dem Z-PI bekannte Patientenidentifikation verwendet werden.

KBS Subsequent Type Handling – ELGA und e-Health¶

				Folge-Transaktion*
KB-Type	Status	berechtigte Rolle (Ident Method)	listKBgda	Amb. Kontakt	Stat. Kontakt	Entl. Kontakt	Delegation	Intern. Kontakt	KB Storno
kein Kontakt						4			5
Stat. Kontakt (K101)	aktiv inaktiv invalidated	702 (kein PIM105 & 106) 703 (kein PIM105 & 106) 716 (nur PIM102 & 103)			1
Amb. Kontakt (K102)	aktiv inaktiv invalid. ignored	700 (nur PIM101 & 105) 701 (nur PIM101) 702 (kein PIM105) 703 (kein PIM105 & PIM106) 704 (nur PIM101) 716 (nur PIM102 & 103) 717 (nur PIM102 & 103) 721 (nur PIM102, 103, 105) 722 (nur PIM102, 103, 105) 724 (nur PIM101, 105 & 106)				2
Entl. Kontakt (K103)	aktiv inaktiv invalidated	702 (kein PIM105 & PIM106) 703 (kein PIM105 & PIM106) 716 (nur PIM102 & 103)				3
Del. Kontakt (K104)	aktiv inaktiv invalidated	Keine Rollen-Beschränkungen				6	7
Intern. Kontakt (K105)	aktiv inaktiv invalidated	729 (PIM101 & PIM107 & PIM108)

Tabelle: KBS Empfangsverhalten

* Die Folge-Transaktion bezieht sich auf eine nachfolgende Transaktion auf einen aktiven KB-Type.

Berechtigte Rolle

700	Arzt
701	Zahnarzt
702	Krankenanstalt
703	Pflegeeinrichtung
704	Apotheke
716	Amtsarzt
717	Korrekturberechtigter
718	Krisenmanager
721	Arbeitsmedizin
722	Hebamme
724	Labor und Pathologie
729	Gesundheitsberatung 1450

Ident Method

PIM101	e-card mit stecken
PIM102	Bürgerkarte
PIM103	L-PI / Z-PI
PIM104	e-card ohne stecken
PIM105	Amtl. Lichtbildausweis / e-card für mobile e-Impfpass Anwendung
PIM106 *	Zuweisung
PIM107	eIDAS konforme Identifikation inklusive ID Austria
PIM108	Identifikation anhand amtlichen Lichtbildausweis

* Anmerkung zu PIM106: Kann nur mit einer gültigen HCP-Assertion (Kontext Assertion Einbringung nicht möglich) eingebracht werden.

Folge-Transaktionen

Erlaubt

Erlaubt (ignored)

Verboten

Allgemeine Fehlermeldungen

key	display
wst:InvalidRequest	Kontakteinmeldung zu weit in der Zukunft
wst:InvalidRequest	Kontakteinmeldung zu weit in der Vergangenheit

Detaillierte Fehlermeldungen - wst:InvalidRequest

1	Stat. Aufnahme auf bereits erfolgte stat. Aufnahme
2	Stationäre Entlassung auf ambulante Aufnahme
3	Stationäre Entlassung auf stationäre Entlassung
4	Entlassung ohne Aufnahme
5	Storno eines Kontakts ohne vorherige Kontakteinbringung
6	Stationäre Entlassung auf delegierten Kontakt
7	Delegierter Kontakt delegiert

Identifizierungsmethode PIM105¶

Die Identifizierungsmethode PIM105 sieht per Definition vor, dass ein(e) Patient(in) mit einem amtlichen Lichtbildausweis oder einer e-card für die mobile e-Impfpass Anwendung identifiziert werden kann. Diese Identifizierung darf ausschließlich nur im Kontext der e-Impfpass Anwendung, mit entsprechender Kontext-Assertion (siehe Beispiel unten) geschehen. Andere Konstellationen werden vom KBS abgelehnt und resultieren in einer allgemeinen Fehlermeldung (siehe bisheriges Fehlerhandling zu PIM101-104).

ELGA Rollen, welchen gemäß genereller Policies ein Zugriff auf den e-Impfpass erlaubt sind, dürfen demnach Kontakte mit PIM105 einbringen.

Ein zusätzliches Regelset ist zu beachten, da es speziell in Verbindung mit PIM105 einen direkten Zusammenhang mit Kontakttyp, Rollen und Identifizierung gibt:

Ein Kontakt mit PIM105

darf im Rahmen des e-Impfpasses zwecks GDA-I Gegebenheiten explizit nur von Ärzten/Ärztinnen (=Rolle 700), Arbeitsmedizin (=721), Hebamme (=722) sowie Labor und Pathologie (=724) eingebracht werden.
darf nur für die Einmeldung ambulanter Kontakte verwendet werden (=K102). Andere Kontakttypen werden vom KBS via Konfiguration abgelehnt.
darf nicht delegiert werden. Nur Einbringung, Abfragung und Stornierung sind möglich.
hat keinen Zugriff auf e-Befunde und e-Medikation.
kann zusätzlich zu bereits vorhandenen aktiven Kontakten mit anderen PIM Identifizierungsmethoden (PIM101-104) eingebracht werden. Diese vorhandenen Kontakte bleiben aktiv. Umgekehrt (PIM105-Kontakt bereits vorhanden, PIM101-104 wird eingebracht) verhält es sich genauso. Lediglich bereits vorhandene PIM105-Kontakte werden bei erneuter PIM105-Kontakteinbringung inaktiv gesetzt. Diese werden auch nur dann reaktiviert, wenn der aktuelle PIM105-Kontakt storniert wird.
ist nicht anwendbar für den Fallartwechsel (weitere Details zum Fallartwechsel dazu siehe BeS Pflichtenheft).

Neben bisher verwendeten KBS-Abfragen ("ListKBS") wird zusätzlich eine neue KBS-Abfrage benötigt, welche ausnahmslos Kontakte mit PIM105 retourniert ("ListKBS_PIM105").

Beispiel e-Impfpass Kontext-Assertion.xml für KBS Abfrage PIM105

Beispiel e-Impfpass ListKBGDA-Request.xml für KBS Abfrage PIM105

Beispiel e-Impfpass ListKBGDA-Response.xml für KBS Abfrage PIM105

	Erlaubt
	Erlaubt (ignored)
	Verboten