ehvd Konzeption Juli

Transkript

1 Juli Der ehealth-verzeichnisdienst (ehvd) ist das Verzeichnis aller Gesundheitsdiensteanbieter (GDA). Die Rechtsgrundlagen für den ehvd sind die 9 und 10 Gesundheitstelematikgesetz 2012 (GTelG 2012) und die Gesundheitstelematikverordnung 2013 (GTelV 2013). Die Konzeption umfasst die direkt der technischen Spezifikation vorgelagerten Entscheidungsgrundlagen zur Umsetzung des ehvd

2 1 1.1 Inhaltsverzeichnis Inhaltsverzeichnis Formales Architektur Das System ehvd Architektur Anlieferung EAS-Anlieferung Registrierung Technische Basisparameter Strukturierung EAS und Verarbeitung Übertragungsprozess Verarbeitungsprozess Einlieferung über Webformular oder Webanwendung Einlieferung über das BMG Kategorisierung der einbringenden GDA Struktur und Datenfelder des ehvd Standards und Terminologien Datenbereiche ehvd Datenbereich Person Struktur Personenstammdaten Identifikatoren Sonstige Daten Rolle Datenbereich Organisation Struktur Stammdaten Identifikatoren Sonstige Organisationsdaten Rolle Datenbereich Organisationseinheit Seite 1

3 6.5.1 Struktur Felddefinitionen Verwendete Kodierungen Erläuterungen Schnittstellen aus dem ehim OID-Schnittstelle KUR-Schnittstelle Geo-Codes-Schnittstelle Abbildung der Felddefinitionen auf das HPD-Schema Datenbereich Person Datenbereich Organisation Datenbereich Organisationseinheit Legende der Optionalitäten...39 Abbildungen Abbildung 1 - ehvd Architekturmodelle... 5 Abbildung 2 Globale Systemsicht... 6 Abbildung 3 Schichten der einzelnen Systeme... 7 Abbildung 4 - EAS Anbindung... 8 Abbildung 5 Anlieferung in den EAS...13 Abbildung 6 Darstellung der Schnittstellen zum ehim...32 Änderungsverlauf 1.0 Inhalte zur Phase Big Picture Piswanger 1.1 Ergänzung von Inhalten zu Piswanger Einlieferung und GDAs 2.0 Ergänzung der Inhalte zur Phase Piswanger Konzeption 2.1 Einfügen der LDAP-Konzeption Schalhaas 2.2 Einfügen zusätzlicher Aspekte Gruber, Winter 3.0 Finalisierung Konzeption Piswanger, Winter 3.1 Versionswechsel und Abgleich Winter 3.2 Finalisierung Gruber, Winter 3.3 Einarbeitung Review-Ergebnis Gruber, Winter 3.4 Einarbeitung Review-Ergebnis Gruber Seite 2

4 2 Formales Beteiligte Auftraggeber Bundesministerium für Gesundheit Ersteller Mag. Engelbert Prenner Bundesrechenzentrum GmbH. Mag. Carl-Markus Piswanger, MSc carl-markus.piswanger@brz.gv.at Christian Gruber, MSc christian.gruber@brz.gv.at Andreas Schalhaas andreas.schalhaas@brz.gv.at Ing. Harald Winter, BSc harald.winter@brz.gv.at Abkürzungen API Application Programming Interface (Schnittstelle) BMG Bundesministerium für Gesundheit BOOL Boolean (Datentyp) BRZ Bundesrechenzentrum GmbH CHAR Character (Datentyp) CSV Comma Separated Value DSA Digital Signature Algorithm EAS Eingangs-Ausgangs-Servicer ehim ehealth Identity Management ERsB Ergänzungsregister Sonstige Betroffene GDA Gesundheitsdiensteanbieter INT Integer (Datentyp) PGP Pretty Good Privacy (Verschlüsselungsprogramm) SFTP Secure File Transfer Protocol UR Unternehmensregister USP Unternehmensserviceportal XML Extensible Markup Language Seite 3

5 3 Architektur Das System ehvd besteht aus mehreren technischen Komponenten, die über technische Schnittstellen miteinander verbunden sind. 3.1 Das System ehvd Das System ehvd besteht aus folgenden Komponenten: Eingangs-Ausgangs-Service (EAS), zur Einlieferung von großen Datenbeständen. Das EAS übernimmt, sichert und übergibt die Datenbestände an den ehim über eine technische Schnittstelle Formularservice im Unternehmensserviceportal (USP), zur Einmeldung und Änderung individueller Datenbestände. Bei Einmeldung und Änderung wird ein Datencontainer (XML) gebildet und über den ELAKimBund zur Bearbeitung/Approbation gesandt und von dort mittels Schnittstelle an den ehim übermittelt. Als Vorlage für den Prozess wird das bestehende Service Neuantrag und Änderung im ERsB herangezogen. E-Health Identity Management (ehim), zur Übernahme, Anreicherung und Aufbereitung der eingelieferten Daten und zur Provisionierung an den ehvd bzw. den GDA-Index. Der ehim empfängt Datenpakete entweder vom EAS (Batch-Einlieferungen) oder vom ELAKimBund (Einzeleinlieferungen). Die einzelnen Datenpakete werden den Voreinstellungen gemäß aufbereitet, gegebenenfalls werden über Schnittstellen zusätzliche Daten abgefragt (siehe Schnittstellen aus dem ehim ). Die aufbereiteten Datenpakete werden kontinuierlich oder terminisiert in den ehvd eingeliefert. E-Health-Verzeichnisdienst (ehvd), übernimmt die Daten vom ehim über eine technische Schnittstelle und speichert diese gemäß dem HPD-LDAP- Schema (IHE) ab. Dabei vergibt er einen Zeitstempel bei jedem Datensatz. Abfrageschnittstellen, eingehend über das Gesundheitsportal (GHP oder ausgehend (siehe Abfragen aus dem ehvd ) Seite 4

6 3.2 Architektur In der folgenden Grafik sind zwei Architekturmodelle unterschiedlicher Dimensionierung dargestellt. Die linke Darstellung stellt einen einfachen Aufbau des ehvd dar, wogegen die rechte Darstellung einen ausfallsgesicherten Aufbau darstellt. Wie in den Grafiken dargestellt, unterscheiden sich die beiden Architekturmodelle in der zentralen ehvd-komponente, wogegen die vorgelagerten Systeme für Einlieferung (z.b. EAS) und Aufbereitung (ehim) von der Dimensionierung gleichbleiben. Organisatorische Prozesse (z.b. Change-Management-Prozesse, Support- Prozesse) werden durch die unterschiedlichen Architekturen ebenfalls nicht berührt. Einfacher Aufbau an einem Standort Redundanter Aufbau mit Lastverteilung Archiv EAS Schnittstellen in EAS USP Formularservice ELAK ehim Schnittstellen aus ehim Produktion ehvd Standort 1 - ehvd Produktion ehvd Standort 1 - ehvd Standort2 ehvd (optional) Application- Server Lastverteiler- Komponente Application- Server Lastverteiler- Komponente Application- Server GHP Suchabfrage LDAP Instanz Intrusion Prevention LDAP Instanz Master Intrusion Prevention LDAP Instanz Slave Intrusion Prevention WS Abfrage Rufbereitschaft 07:00 17:00 Help-Desk (1st-Level Support für ehvd-betrieb) Rufbereitschaft 07:00 17:00 Help-Desk (1st-Level Support für ehvd-betrieb) QS-Umgebung (Test) Standort 1 ehvd Application- Server LDAP Instanz Betriebsführung ehvd Release-Management Neue Version auf Prod. nur durch BRZ-Betrieb entspr. Vorgaben ITIL Change Management Aktuell halten aller Systemkomponenten Problem Management Analyse von Störungen und Erstellen von Lösungsvorschlägen Security Management empfohlenes Verfahren bzgl. Security Patches Durchführung monatl. Vulnerability-Tests Betrieb Organisatorische periodische Abstimmung Kunde / Fachbereich / Betriebsführung 2nd- Level Support für ehvd- Fachbereich Abbildung 1 - ehvd Architekturmodelle Seite 5

7 Das obige Architekturmodell zeigt sowohl die produktive Plattform des ehvd, in dem die jeweils aktuellen Echtdaten vorliegen, als auch das QS-System (Qualitätssicherung), das der Einlieferung von Daten der Registrierungsstelle im Fall von Änderungen bzw. Erweiterungen an der Schnittstelle dient, um vorab sicherstellen zu können, dass der an allen beteiligten Stellen angepasste Anlieferungs- bzw. Abfrageprozess für einen produktiven Einsatz herangezogen werden kann. Das produktive System kann optional an zwei physischen Standorten (Rechenzentren) aufgebaut und dadurch zur Ausfallssicherheit redundant gehalten werden. Zusätzlich ergibt sich dadurch die Möglichkeit zur Verteilung der Zugriffslast auf zwei verarbeitende Instanzen. 4 Anlieferung Die Einlieferung erfolgt einerseits durch die Registrierungsstellen mittels CSV und XML, andererseits über das Unternehmensserviceportal (USP Formularservice). Die angelieferten Daten werden im ersten Schritt im ehim eingebracht. In der weiteren Verarbeitung werden die Daten durch Mapping in die Struktur der jeweils geforderten Zielsysteme (z.b. ehvd) umgeformt (Provisionierung). Abbildung 2 Globale Systemsicht Seite 6

8 Abbildung 3 Schichten der einzelnen Systeme Es bestehen drei Einlieferungskanäle in den ehvd: Die Einlieferung über den EAS (Listen-Einlieferung) Die Einlieferung über Formular oder Webanwendung (Einzeleinlieferung) Die Einlieferung direkt über das BMG Bei einer Anlieferung über den EAS ist eine einmalige Abstimmung zum übermittelten Format notwendig. Die dabei anzuwendende Datenstruktur ist den Ausführungen im Abschnitt 6 Struktur und Datenfelder des ehvd zu entnehmen. Durch eine Testübermittlung und Verarbeitung wird die Korrektheit der Datenstruktur überprüft. Eine allenfalls notwendige Nachbesserung wird (Registrierungsstellenseitig) initiiert Seite 7

9 4.1 EAS-Anlieferung Die Einlieferung über das EAS des BRZ ist die zentrale Methode für die Registrierungsstellen, die Batch-Einlieferungen in den ehim durchführen. Im Folgenden ist die Funktionsweise der Einlieferung beschrieben. Abbildung 4 - EAS Anbindung Seite 8

10 4.1.1 Registrierung Bevor eine Anlieferung durchgeführt werden kann, ist die einmalige Registrierung und Freischaltung der Registrierungsstelle notwendig. Dieser Schritt wird initiiert durch ein an den Postkorb unter bekanntgabe nachstehender Informationen. 1. Bezeichnung der Registrierungsstelle inkl. der betreuten GDAs 2. Kontaktdaten/Kontaktperson der Registrierungsstelle für allfällige Kommunikationsaufnahme Anhand dieser Daten wird die Legitimation zur Datenanlieferung überprüft. Das Ergebnis wird an die Registrierungsstelle zurückgemeldet. Danach sind die technischen Basisparameter auszutauschen Technische Basisparameter Der Hostnamen des EAS lautet eas.cna.at für die Einlieferung in die produktive Umgebung oder eas-test.cna.at für die Einlieferung in die Testumgebung. Es ist immer nur der Hostname zu verwenden, da das EAS über zwei Standorte aufgebaut ist. Grundsätzlich müssen die IP-Adressen der anliefernden Registrierungsstelle für den Zugang zum EAS explizit vom Betreiber freigeschalten werden. Aus diesem Grund ist es notwendig, dass externe Partner, die aus dem Internet auf den EAS zugreifen wollen, eine fixe IP-Adresse bekanntgeben, die dann auf der BRZ-Firewall freigeschalten wird. Der Zugang zum EAS in der Implementierungsphase kann mit einem selbstgenerierten Zertifikat erfolgen (DSA-Key 1024 Bits). Für den produktiven Betrieb ist die Verwendung eines durch einen akkreditierten Austeller erstellten Zertifikates zu empfehlen. Die größte Herausforderung in diesem Projekt ist die Sicherstellung der Datenintegrität und Datensicherheit. Daher sind alle Anstrengungen zu unternehmen, um eine Man-in-the-Middle -Attacke auszuschließen. Die Empfangsstelle muss daher überprüfen können, ob das Datenpaket unverändert angekommen ist (Verschlüsselung mit public key des EAS) und das Datenpaket von der Sendestelle in den Empfangsordner gestellt wurde (Signierung mit private Key der Sendestelle). Das für die symmetrische Verschlüsselung und Signierung notwendige Key-Pair kann durch Tools selbst generiert werden. Somit wird benötigt: 1. ein Zertifikat für den SFTP-Zugang (in Produktion Offizielles) Seite 9

11 2. ein Key-Pair für Verschlüsselung und Signierung (public Key als DSA-Key mit 1024 Bits an das BRZ unter übermitteln) 3. Die IP-Adresse, von der der SFTP-Client auf den EAS zugreift (ebenfalls an das BRZ zu übermitteln) Der Hostname des EAS im Produktivsystem lautet: eas.cna.at SFTP Port: 22 (Standard Port) Der Hostname des EAS im Testsystem lautet: eas-test.cna.at SFTP Port: 22 (Standard Port) Für das Prozedere der Verschlüsselung und Signierung sendet der Partner seinen Public-Key, mit welchem er Daten signiert bzw. Rückdaten an ihn verschlüsselt werden sollen. Im Gegenzug dazu stellt das BRZ den eigenen Public-Key für das Verschlüsseln der eigentlich anzuliefernden Daten bereit. Der Partner bekommt die Zugangsdaten seitens BRZ zugeschickt Strukturierung EAS und Verarbeitung Die Registrierungsstelle stellt ihre Daten in das in -Verzeichnis und holt für sie bestimmte Daten aus dem out -Verzeichnis (fakultativ). Falls fakultative Daten, wie z.b. Bestätigungen, im out -Verzeichnis verschlüsselt werden, bekommt die Registrierungsstelle einen Public-Key zum Entschlüsseln mit den Zugangsdaten zugeschickt. Im EAS wird für jede Registrierungsstelle ein Verzeichnissystem angelegt, das folgende Struktur hat: <Partner-Root> <Test> <in> <out> <Produktion> <in> <out> Die aufbereiteten ehvd-daten können optional in folgender Struktur für die Abholung durch die gemeldeten Datenkonsumenten (siehe auch 4.2.3) bereitgestellt werden: LDAP <Test> <out> <Produktion> <out> Seite 10

12 Der tägliche Verarbeitungsprozess stellt dazu einen LDIF-Datenbestand in das jeweilige OUT-Verzeichnis. Dieser Datenbestand wird mit den public Keys der gemeldeten Datenkonsumenten verschlüsselt und mit dem privaten Schlüssel des BRZ signiert. Der Datenstand steht in seiner aktuellen Version täglich ab 16:00 zur Abholung bereit. Der Aufbau der Filebenennung ist wie folgt: ehim_export.ldif_jjjjmmtt.gpg Übertragungsprozess Die Registrierungsstelle muss sicherstellen, dass die Filenamen, solange die Übertragung zum EAS nicht abgeschlossen ist, als temporär gekennzeichnet sind. Als Kennzeichen dafür werden die File-Extensions tmp und filepart akzeptiert: <eigentlicher Filname>.tmp <eigentlicher Filename>.filepart Bsp: Der WinSCP Client (Freeware verwendet default-mäßig beim Übertragen die temporäre Endung filepart. Die Files werden von einem Prozess im EAS an die Backend-Verarbeitung weitergereicht. Ist dies geschehen, werden die Files in ein Schattenverzeichnis verschoben und sind somit im eigentlichen Eingangsordner nicht mehr sichtbar. Der Aufbau des Filenamens muss das Tagesdatum beinhalten (Bsp: Org_ xml), damit das Anlieferungsfile eindeutig identifiziert werden kann. Jede Datenanlieferung wird in verschlüsselter als auch entschlüsselter Form für die Dauer von drei Jahren in einem Archiv unveränderlich abgelegt Verarbeitungsprozess Unabhängig von etwaigen Änderungen im Datenbestand ist von den Registrierungsstellen stets ein Vollbestand zu übermitteln. Die Einlieferung via USP/ELAK erfolgt im Anlassfall und nach Freigabe durch die Registrierungsstelle (BMG). Die Datenanlieferungen haben gemäß den 6 bis 8 GTelV 2013 von der jeweils zuständigen Registrierungsstelle bei - Eintragungen durch Übermittlung aus Registern täglich (an Arbeitstagen) - Eintragungen durch elektronische Meldungen zumindest einmal monatlich und Seite 11

13 - Einzeleintragungen anlassbezogen zu erfolgen. Nachstehend das Schaubild über die Zeitschiene der Verarbeitung des ehvd- Systems: Seite 12

14 00:00 Anlieferungszeitraum 12:00 Verarbeitungszeitraum 16:00 Abholungszeitraum 24:00 09:00 Betreute Betriebszeit Unbetreute Zeit Unbetreute Zeit 17:00 Start Datenanlieferung durch Registrierungsstelle Signaturkontrolle, Entschlüsselung und Archivierung Kontrolle Eckparameter (Schwellwert, Signatur) Eckparameter OK? Ja Aufarbeiten der Daten Erstellung tagesaktueller GDA- Bestand Verschlüsselung, Signatur und Archivierung Datenabholung durch GDA-Daten- Konsument (Domänen) Ende 2 Nein Verständigung Betriebsführung Erstellen Verarbeitungsstatistik und Fehlermeldungen Ende 1 Datenabholung durch Registrierungsstelle Verschlüsselung, Signatur und Archivierung Erstellung Rückmeldung Abbildung 5 Anlieferung in den EAS

15 Die Daten müssen bis 12:00 Uhr angeliefert werden. Danach angelieferte Daten werden erst am Folgetag verarbeitet. Idealerweise erfolgt dies bis spätestens 10:00 Uhr, um bei erkannten Fehlern noch reagieren zu können. Die Backend- Verarbeitung läuft von 12:00 bis längstens 16:00 Uhr, danach können Verarbeitungsstatistiken bzw. der aufgearbeitete Datenbestände abgeholt werden. 4.2 Einlieferung über Webformular oder Webanwendung Die Einlieferung über Webformular oder Webanwendung dient der Einbringung von Einzelmeldungen in den ehvd. Da viele/alle GDA dieser Kategorie Organisationen in einem der Quellregister (Firmenbuch, Vereinsregister, ERsB) und dadurch im UR integriert sind, ist eine Integration in das USP vorteilhaft. Auf Grund der Komplexität der einzuliefernden Daten (v.a. Abhängigkeiten) ist eine Evaluation der Durchführbarkeit als Webformular vorzunehmen und gegebenenfalls als Webapplikation umzusetzen. Als Modell für die Evaluierung ist die Anwendung Neuantrag und Änderung in das Ergänzungsregister Sonstige Betroffene (ERsB) zu empfehlen. 4.3 Einlieferung über das BMG Bestimmte GDA werden aus Registern/Listen des BMG direkt in den ehvd eingebracht. - Krankenanstalten: Die gemäß Dokumentationsgesetz erfolgenden Datenmeldungen der Registrierungsstellen gemäß GTelG 2012 an das BMG werden im Krankenanstaltenkataster erfasst. - Psychologen, Psychotherapeuten, Klinische und Gesundheitspsychologen, Musiktherapeuten und Kardiotechniker werden in den von den diesbezüglichen Berufsgesetzen vorgesehenen Listen erfasst. Technisch wird diese Einlieferung der Daten, wie in der Einlieferung über das EAS beschrieben, über das BMG-Service Bagdad durchgeführt

16 5 Kategorisierung der einbringenden GDA EAS-Einlieferung GDA Verzeichnis Registrierungsstelle 1 Ärztin/Arzt für Ärzteliste Österreichische Ärztekammer Allgemeinmedizin 2 Approbierte Ärztin/ Ärzteliste Österreichische Ärztekammer Approbierter Arzt 3 Fachärztin/Facharzt Ärzteliste Österreichische Ärztekammer für < > 4 Ärztliche Ärzteliste Österreichische Ärztekammer Gruppenpraxis 5 Zahnarzt Zahnärzteliste Österreichische Zahnärztekammer 6 Fachärztin/Facharzt für Zahnärzteliste Österreichische Zahnärztekammer ZMK 7 Dentistin/Dentist Zahnärzteliste Österreichische Zahnärztekammer 8 Zahnärztliche Zahnärzteliste Österreichische Zahnärztekammer Gruppenpraxis 9 Hebamme Hebammenregister Hebammengremium 10 Selbstständiges Land Ambulatorium 11 Öffentliche Apotheke Apothekenliste Österreichische Apothekerkammer 12 Pflegeeinrichtungen Land 13 Sozialversicherung Hauptverband der Sozialversicherungsträger EAS-Einlieferung BMG GDA Verzeichnis Registrierungsstelle 1 Psychotherapeutin/ Psychotherapeutenliste BMG Psychotherapeut 2 Klinische Psychologin/ Psychologenliste BMG Klinischer Psychologe 3 Gesundheitspsychologin Psychologenliste BMG /Gesundheitspsychologe 4 Musiktherapeutin/ Musiktherapeutenliste BMG Musiktherapeut 5 Dipl. Kardiotechnikerin/ Kardiotechnikerliste BMG Dipl. Kardiotechniker 6 Allgemeine Krankenanstaltenkataster Land Krankenanstalt 7 Sonderkrankenanstalt Krankenanstaltenkataster BMG 8 Pflegeanstalt Krankenanstaltenkataster Land 9 Sanatorium Krankenanstaltenkataster Land 10 Ombudsstelle BMG 11 Widerspruchstelle BMG Seite 15

17 Einlieferung über USP GDA Verzeichnis Registrierungsstelle 1 Heilmasseurin/ BMG Heilmasseur 2 Mobile Pflege BMG 3 Kuranstalt BMG 4 Untersuchungsanstalt BMG 5 Gewebebank BMG 6 Gewebeentnahmeeinrichtung BMG 7 Blutspendeeinrichtung BMG 8 Rettungsdienst BMG 9 Arbeitsmedizinisches BMG Zentrum 10 Augen- und BMG Kontaktlinsenoptik 11 Hörgeräteakustik BMG 12 Orthopädische Produkte BMG 13 Zahntechnik BMG 14 Gesundheitsmanagement BMG 15 Öffentlicher BMG Gesundheitsdienst 16 Patientenvertretung BMG 17 Krankenfürsorge BMG 18 Gesundheitsversicherung BMG 19 IKT-Gesundheitsservice BMG 20 Verrechnungsservice BMG Klärungsbedarf (offen) GDA Verzeichnis Registrierungsstelle 1 Straf- und Maßnahmenvollzug 2 Physiotherapeutin/ Physiotherapeut 3 Radiologietechnologin Radiologietechnologe 4 Biomedizinische Analytikerin/ Biomedizinischer Analytiker 5 Diätologin/Diätologe 6 Ergotherapeutin/ Ergotherapeut 7 Logopädin/Logopäde 8 Orthoptistin/Orthoptist Seite 16

18 9 Diplomierte Gesundheits- und Krankenschwester/Diplomierter Gesundheits- und Krankenpfleger 10 Diplomierte psychiatrische Gesundheits- und Krankenschwester/ Diplomierter psychiatrischer Gesundheits- und Krankenpfleger 11 Diplomierte Kinderkrankenschwester/ Diplomierter Kinderkrankenpfleger Seite 17

19 6 Struktur und Datenfelder des ehvd Im folgenden Kapitel ist die Datenstruktur zur Einlieferung von Datensätzen in den ehvd zu finden. Die dargestellten Bereiche sind: Datenstruktur inkl. Hierarchien Datenfelder inkl. allfälligen Erläuterungen Hinweise auf Kodierungen (Codelisten, Standards) und Mappings Felddefinitionen (Typ, Länge, Kardinalität, Verbindlichkeit) Der ehvd enthält folgende Datenbereiche Person Organisation Organisationseinheit 6.1 Standards und Terminologien Schreibweise von Datums- und Zeitangaben ISO 8601 Datenelemente und Austauschformate; Informationsaustausch; Darstellung von Datum und Uhrzeit Als Trenner von Datumselementen ist der Bindestrich, von Zeitelementen der Doppelpunkt zu verwenden. Beispiele: Datum: JJJJ-MM-TT ( ) Zeit: hh:mm:ss (16:25:33) Bei Datums- und Zeitangaben in Dateinamen entfallen die Trenner. Beispiel: JJJJMMTT: testdaten_ test Schreibweise von Telefonnummern E.123: Empfehlung der Internationalen Fernmeldeunion (ITU-T) Die Trennung von Landeskennzahl, Ortsnetzkennzahl, Ruf- und Nebenstellennummer erfolgt durch Leerstellen, Verkehrsausscheidungskennziffern unterbleiben. Beispiel: Seite 18

20 Mobiltelefonnummer: Festnetznummer: Codierung von Länderkennungen ISO : Codierung von geografischen Einheiten in der Ausprägung Alpha-2 Für die Umsetzung ist das diesbezügliche Value Set zu verwenden. Codierung von Sprachen ISO 639-1: Kennungen für Namen von Sprachen Für die Umsetzung ist das diesbezügliche Value Set zu verwenden Seite 19

21 6.2 Datenbereiche ehvd <ehvd> <Person/> <Organisation/> <Organisationseinheit/> </ehvd> 6.3 Datenbereich Person Struktur <Person> <PersStammdaten/> <PersIdentifikatoren/> <PersSonstigeDaten/> <PersRolle/> </Person> Personenstammdaten Hier wurde aus einer Synergiebestrebung heraus auf die PersonData- Spezifikation des Bundes Bezug genommen Struktur <PersStammdaten> <Name/> <Titel/> <Geschlecht/> <Geburtsdatum/> <Geburtsort/> <Staatsangehörigkeit/> <Fremdsprache/> </PersStammdaten> Felddefinitionen Person Information T L K V Stammdaten 1-1 M Name 1-1 M Vorname CHAR n M Zuname CHAR M Titel 0-1 O TitelVor CHAR 50 0-n O TitelNach CHAR 50 0-n O Geschlecht Liste 09 CHAR R Geburtsdatum ISO 8601 DATE R Geburtsort CHAR R Staatsangehörigkeit Liste M StaatCode CHAR M StaatName CHAR M Seite 20

22 Fremdsprache Liste 12 0-n O SprachCode CHAR 2 1-n M SprachName CHAR M Verwendete Kodierungen Geschlecht (Liste 09) Länderkennung (Liste 11) Sprachkennung (Liste 12) Identifikatoren Struktur <PersIdentifikatoren> <Wirtschaft/> <Government/> <Objektkennung/> <FremdID/> </PersIdentifikatoren> Felddefinitionen Person Information T L K V Identifikatoren 1-1 M Wirtschaft Schnittstelle UR 0-1 O KUR_Kennung OID der KUR CHAR M KUR_Value CHAR M KUR_Type CHAR M KUR_Authority CHAR M Government bpk-gh 1-1 M Gov_Kennung OID des bpk-gh CHAR M Gov_Value Base64-codiert CHAR M Gov_Type CHAR M Gov_Authority CHAR M Objektkennung 1-1 M OID_Value CHAR M OID_Type CHAR M OID_Authority CHAR M OID_SymbValue CHAR O FremdID 0-n O FremdID_Kennung OID der FremdID CHAR M FremdID_Value CHAR M FremdID_Type CHAR M FremdID_Authority CHAR M Erläuterung einzelner Datenfelder Government- und Wirtschaftsidentifikatoren wurden aufgrund ihrer besonderen Bedeutung aus den Fremdidentifikatoren ausgenommen. Die KUR wird über eine Schnittstelle zum Unternehmensregister ergänzt. Mit ihr werden die Angaben betreffend Berufssitz plausibilisiert ist keine KUR vorhanden, werden diesbezügliche Angaben in den Datenmeldungen verworfen Seite 21

23 Als Authority ist jeweils jene Entität aufzunehmen, in deren Verantwortlichkeit der betreffende ID vergeben wurde. Bezüglich der Objektkennung ist dies mit wenigen Ausnahmen das Bundesministerium für Gesundheit (EHSREG). Das Feld OID_SymbValue enthält den symbolischen Bezeichner gemäß ÖNORM A 2642, auf die dort festgelegten Bildungsregeln wird verwiesen. Das Feld wird im Zuge der Erstregistrierung (bzw. bei der Vergabe der OID durch die EHSREG) nicht befüllt. Wird im Zuge der operativen Verwendung des ehvd ein entsprechender Bedarf festgestellt, ist ein entsprechender Prozess zur Ergänzung/Berichtigung aufzusetzen Sonstige Daten Struktur <PersSonstigeDaten> <Kommunikation/> <KryptoAngaben/> </PersSonstigeDaten> Felddefinitionen Person Information T L K V Sonst. Daten 0-1 O Kommunikation 0-1 O Mobiltelefon ITU-T E.123 CHAR 20 0-n O Web ITU-T E.123 CHAR O KryptoAngaben 0-n O KryptoZweck CHAR O KryptoZert Default = FALSE BOOL M KryptoValue ITU-T E.123 (link), X.509 CHAR M Zertifikat (DER, CER, CRT, PEM) Verwendete Kodierungen Schreibweise von Mobiltelefonnummern und der Links entsprechend der Empfehlung der Internationalen Fernmeldeunion Erläuterungen Das Segment Kommunikation ist für nicht ortsgebundene Angaben reserviert. Derzeit können nur Mobiltelefonnummern und Webadressen hinterlegt werden. Im Feld KryptoZweck kann eine Angabe hinterlegt werden, wofür das im Feld KryptoValue verlinkte oder als Datei enthaltene - Zertifikat verwendet werden soll. Bleibt das Feld leer, wird davon ausgegangen, dass das adressierte Zertifikat generell für die Verschlüsselung von Gesundheitsdaten verwendet werden kann. Bleibt die Default-Einstellung im Feld KryptoZert unverändert, wird im Feld KryptoValue ein Link (Adresse) auf das Zertifikat erwartet, ansonsten das Zertifikat in einem der angegebenen Formate Seite 22

24 6.3.5 Rolle Struktur <PersRolle> <RolleID/> <RolleBezDE/> <RolleBezEN/> <Spezialisierung/> <Zusatzqualifikation/> <Berechtigung/> <Befugnis/> <SHA/> <ELGA/> <Registrierungsdaten/> <Berufssitz/> <Dienstgeber/> </PersRolle> Felddefinitionen Person Information T L K V Rolle 1-n M RolleID Liste 01 INT M RolleBezDE CHAR M RolleBezEN CHAR O Spezialisierung Liste 03 0-n R SpezCode INT M SpezBezDE CHAR M SpezBezEN CHAR O Zusatzqualifikation Liste 04 0-n R ZqCode INT M ZqBezDE CHAR M ZqBezEN CHAR O Berechtigung 0-1 O BerechtBeginn ISO 8601 DATE M BerechtStat Active/Inactive CHAR M BerechtEnde ISO 8601 DATE O Befugnis Liste 05 0-n O BefCode INT M BefBezeichnung CHAR M BefBehörde CHAR M BefRegDat ISO 8601 DATE M SHA Liste M SHA_HPCode CHAR M SHA_BezEN CHAR M ELGA 1-1 M FlagGDAI BOOL M ElgaAggCode Liste 10 INT R ElgaAggBez CHAR R Registrierungsdaten 1-1 M RegStelleCode Liste 02 INT M RegStelleBez CHAR M ErstRegDat ISO 8601 DATE O LetzteRegÄndDat ISO 8601 DATE M Berufssitz 0-n R Anschrift Inkl. Hausnummer CHAR M PLZ CHAR M Ort CHAR M GKZ CHAR O Bezirk Nur wenn GKZ verfügbar CHAR O Bundesland Nur wenn GKZ verfügbar CHAR O GeoLng CHAR R GeoLat CHAR R NUTS1 CHAR O NUTS2 CHAR O VZ CHAR O VR CHAR O Festnetz ITU-T E.123 CHAR O ITU-T E.123 CHAR O Barrierefreiheit BOOL M Dienstgeber 0-1 O DG_Name Freitext CHAR O Seite 23

25 DG_Anschrift Inkl. Hausnummer CHAR O DG_PLZ CHAR O DG_Ort CHAR O Verwendete Kodierungen GDA-Rollen (Liste 01) Spezialisierungen (Liste 03) Zusatzqualifikationen (Liste 04) Befugnisse (Liste 05) SHA HP Code (Liste 06) ELGA-Aggregatrollen (Liste 10) Registrierungsstellen (Liste 02) Erläuterungen Die englischen Bezeichnungen der Rolle, der Spezialisierung und der Zusatzqualifikation werden zu einem späteren Zeitpunkt ergänzt. Die Verbindlichkeit R bezüglich der Segmente Spezialisierung und Zusatzqualifikation bezieht sich vorerst nur auf Datenübermittlungen aus der Ärzteliste, da daraus via Mapping die vollständigen Facharztrollen generiert werden; für andere Berufsgruppen sind die Angaben zu diesen Segmenten optional. Die Zuordnung von Additivfächern zum jeweiligen Sonderfach unterbleibt (keine Auflösung von n:m-beziehungen). Berufsberechtigungen in mehreren Sonderfächern werden somit nicht als Mehrfachrollen, sondern über Mehrfachangaben im Segment Spezialisierungen abgebildet. Andere Registrierungsstellen können die Segmente Spezialisierung und Zusatzqualifikation erst dann verwenden, wenn dem BMG ein entsprechender Vorschlag zur Aufnahme in die Mapping-Tabelle übermittelt wird bzw. die Tabelle entsprechend ergänzt wurde. Das Segment Berechtigung enthält als Beginndatum jenes Datum, mit dem erstmalig die Berufsberechtigung in der angegebenen Rolle (ungeachtet allfälliger späterer Erweiterungen der Berechtigungen, z.b. Hinzukommen eines Sonderfachs) erworben wurde. Der Voreinstellungswert des Feldes BerechtStat ist Active. Es darf nur im Zuge der Verarbeitung im ehim auf Inactive gesetzt werden, wenn der GDA im Anlieferungsdatenbestand nicht mehr enthalten ist. Andere Werte (gemäß HPD-Schema) sind unzulässig. Das Feld BerechtEnde ist mit dem Verarbeitungsdatum zu befüllen, wenn eine Statusänderung auf Inactive erfolgt. Im Segment SHA (A System of Health Accounts, 2011 Edition) wird die GDA- Rolle auf die Classification of Health Care Providers ICHA-HP gemappt. Das Datenfeld FlagGDAI dient zur Kennzeichnung der vom ELGA-Gesetz berechtigten ELGA-GDA, die gemäß 19 Abs. 1 GTelG 2012 in den Gesundheitsdiensteanbieter-Index (GDA-Index) übernommen werden. Der Voreinstellungswert ist FALSE. Die Angaben zur Aggregatrolle (ElgaAggCode Seite 24