Widerlegung des eGK-Urteils vom 21.06.2016, Az. L11 KR 2510/15

Widerlegung des eGK-Urteils vom 21.06.2016, Az. L11 KR 2510/15
Die wahre Dimension der Datenerhebung mit der eGK
rdlenkewitz. 23.7.2016
Aktuell wurde vor dem Landessozialgericht in Stuttgart ein weiteres ablehnendes Urteil gesprochen. Ein IT-Ingenieur wollte
grundsätzlich geklärt wissen, ob er zukünftig die elektronische Gesundheitskarte nutzen müsse, wenn er Leistungen der gesetzlichen
Krankenversicherung in Anspruch nehmen wolle. Das Sozialgericht Karlsruhe bejahte dies und wies seine Klage ab. Siehe
http://www.landessozialgericht-baden-wuerttemberg.de/pb/,Lde/Startseite/Presse/Einfuehrung+der+elektronischen+Gesundheitskarte+ist+rechtmaessig_+aber+Behoerden+duerfen+nicht+beliebig+viele+Daten+sammeln/?
LISTPAGE=3790062
Die ablehnende Beurteilung orientiert sich erneut am übergeordneten BSG-Urteil zur eGK. Die Kernaussagen der Pressestelle des
Gerichtes in dem abweisenden Urteil, die sie im Artikel nachlesen können, sind:
1.
Für die Erhebung, Nutzung und Verarbeitung einer Reihe von sensiblen Daten ist die Einwilligung der Versicherten erforderlich; dies wird durch
verschiedene Regelungen zum Datenschutz und zu Maßnahmen zur Verhinderung missbräuchlicher Verwendung flankiert. Damit wird insgesamt
sichergestellt, dass der „gläserne Patient“ nicht Wirklichkeit wird.
2.
Angaben über spezialfachärztliche Versorgung u.a.) auf der Karte gespeichert werden sollen, dürfte dies nicht von der gesetzlichen Ermächtigung
gedeckt und unzulässig sein. Im vorliegenden Fall war der Versicherte jedoch von keinem dieser zusätzlichen Merkmale betroffen, weshalb er
nicht in seinen Rechten verletzt war.
Die weitere Grundlage für diese Beurteilung ist der bekannte § 291 Abs. 1 Satz 1 und 2 und Abs. 2 Satz 1 SGB V, in dem eine
1
begrenzte Anzahl von 10 Datensätzen definiert ist, die mit und über die eGK erhoben werden.
Die Leitsätze im Urteilstext lauteten:
[
Der Umstand, dass die eGK geeignet sein muss, die in § 291a Abs 3 SGB V aufgeführten Anwendungen zu unterstützen, führt nicht
zu einem Verstoß gegen das Recht auf informationelle Selbstbestimmung der Versicherten, da das Erheben, Verarbeiten und Nutzen
von
Daten
zu
diesem
Zweck
nur
mit
der
Einwilligung
der
Versicherten
gestattet
ist.
Die eGK darf ohne Einwilligung des Versicherten nur die in § 291a Abs 1 SGB V genannten Daten enthalten. Unbestimmte
Rechtsbegriffe wie zB der Begriff "Versichertenstatus" dürfen nicht durch (normsetzende) Vereinbarungen im Range unterhalb des
Parlamentsgesetzes ausgefüllt und "datenmäßig erweitert" werden.
]
Die nachfolgende Widerlegung des Urteils erfolgt über die technischen Quelldokumente der gematik mbH-Berlin zur
elektronischen Gesundheitskarte und Telematik-Infrastruktur.
Die Systematik der elektronischen Gesundheitskarte und Telematik-Infrastruktur wird in der Hauptsache durch den Einsatz von XMLTechnologien und Methoden der Verarbeitung von eHealth-Daten in der Telemedizin bestimmt.
Die erweiterbare Auszeichnungssprache XML (Extensible Markup Language) und die dazugehörigen Varianten gezielter
Datenweiterverarbeitung, zu denen die XML-Schemen (XSD), eine Art von Regelanweisungen und Funktionserweiterungen für die
Daten gehören, stellen einen umfangreichen Wissenschaftsbereich in der Informationstechnologie dar.
Die Verarbeitung der
Informationen und Daten der Versicherten mit XML bedeutet in der einfachsten denkbaren Erklärung, dass die Informationen in
zusätzliche Töpfe gepackt werden, die einen eindeutigen Namen haben und zusätzliche Funktionen ermöglichen.
2
grafik rdl 2015
XML ist mit einer Matroschka-Puppe vergleichbar! Für jede Information existiert ein Behälter, der mit umfangreichen weiteren
Informationen ergänzt wird. XML ermöglicht als Grundlage die semantische Interoperabilität, die sektor-übergreifende Komminukation
und den Austausch von Daten und Informationen zwischen allen Teilen des bestehenden Deutschen Gesundheitswesens.
!
Eine Folge des Einsatzes von XML ist der Umstand das automatisch Daten erhoben werden, ohne das eine Zustimmung
des Versicherten eingeholt wird (Stichwort: Informationselemente, ZERO-Information, Negativ-Informationen, siehe
Nachweisführung in Folge ).
Die Annahme des Stuttgarter Landessozialgerichtes
„...das Erheben, Verarbeiten und Nutzen von Daten zu diesem Zweck ist nur mit der Einwilligung der Versicherten gestattet.“
wird durch die Anwendungen von XML zur vollständig falschen Einschätzung.
3
Das eGK-Urteil vom 21.06.2016, Az. L11 KR 2510/15 hat den Einsatz vom XML und XSD in der Verarbeitung der sensiblen
Versichertendaten nicht erkannt und berücksichtigt. Die Verarbeitung der Versichertendaten im Allgemeinen, ohne zunächst eine
nähere Spezifikation und Unterscheidung, z.B. in Versichertenstammdaten und Medizindaten durchzuführen, erfolgt vollständig über
XML- und verwandte Technologien.
!
Grundsätzlich kann keine Beurteilung der Sachverhalte durch Gerichte erfolgen, wenn die maßgebenden Grundlagen der
Speicherung, der Produktion, der Erweiterung und des Transportes der Daten ausgeklammert werden. Diese
maßgebenden Grundlagen werden noch von weiteren elementaren Entwicklungen determiniert, die im Rahmen der
laufenden Umwandlung des Deutschen Gesundheitssystems zur Telematik-Infrastruktur stattfinden.
Eine der wesentlichen Punkte dieser weiteren Entwicklung sind die spezifischen Anpassungen der Primärsysteme, also
der bestehenden Software, die im Deutschen Gesundheitswesen eingesetzt wird.
Die Rechtskräftigkeit des Urteils ist damit nicht gegeben.
Auch die fiktive Situation eines Gerichtes, welches in einem laufenden Verfahren die Erweiterung und die
Weiterverarbeitung der Versichertendaten mit XML und XSD und neuer angepasster Software erkennt und
berücksichtigt führt unweigerlich dazu, dass ohne den Einsatz spezialisierte Gutachter, eine ausreichende Beurteilung
eines der größten IT-Projekt der Welt nicht erfolgen kann.
Die Gründe dafür liegen in der Dimension und Komplexität des größten informationstechnologischen Projekts (IT-Projekts) der Welt,
dem neuen Deutschen Gesundheitssystems (= Telematik-Infrastruktur = TI) und der Vermischung unterschiedlicher
Kerntechnologien, die heute zur Verfügung stehen.
4
Für die Aufklärung, Analyse und Beurteilung muss folgendes Schema für das System berücksichtigt werden:
5
Die Grafik verdeutlicht in schematischer Form den Fluss der Informationen, mittels der elektronischen Gesundheitskarte auf Basis von
XML und XSD-Eweiterungen, in Richtung der technischen Infrastruktur der Rechenzentren oben und nach rechts in die für diese
Zwecke angepasste Software der Primärsysteme. Die gematik zählt zu den Primärsystemen folgende Bereiche des
Gesundheitswesens:
1. Arzt & Zahnarzt (PVS)
2. Krankenhaus (KIS)
3. Apotheker (AVS)
4. eKiosk
5. Versicherter@Home
Die folgenden Ausführungen konzentrieren sich zunächst auf den Einsatz von XML, der erweiterbaren Auszeichnungssprache mit
denen alle Gesundheits und Medizindaten verarbeitet werden.
Die Daten der Versicherten auf der eGK werden über die folgenden XML-Dokumente (Datenblöcke) gruppiert:
1. UC_AllgemeineVersicherungsdatenXML
2. UC_PersoenlicheVersichertendatenXML
3. UC_GeschuetzteVersichertendatenXML
+
4. Schema_VSD.xsd
6
Stellen Sie sich zunächst diese 4 Dateien als lesbare Textdokumente vor, die einen hohen Seitenumfang haben. Über diese
erweiterten Textdokumente wird die Verarbeitung der Versichertendaten gesteuert!
Hinweis: Exemplarisch wird der vollständige Datensatz der Schema_VSD.xsd im Anhang aufgeführt.
In der Regel sind XML-basierende Dokumente mit der Endung *.xml einzelne Textfiles in dessen Kopfteil die Schemaressourcen *.xsd
(Regelanweisungen) mit der <include> Anweisung eingebunden sind. Im Falle der eGK-Systematik wurden die 3 XML-Datenblöcke
zusammengefasst und können über die verknüpfte Schema_VSD.xsd nachvollzogen werden. Die Elementnamen, also die einzelnen
Informationselemente wie z.B. Vor- und Nachname können in den XML-Dokumenten wiedergefunden werden.
Trotz der umfangreichen Veröffentlichung der Systemdetails im Internet gibt es nur einige wenige Beispiele für das Aussehen von
XML-Dokumenten selbst.
In dem DKG-Dokument der Deutschen Krankenhausgesellschaft mit dem Titel:
„Telematikkonformität Release 0 Profil Versichertenstammdaten 13. Mai 2014“
7
findet sich auf Seite 30 ein Beispiel für die mit Daten befüllten XML-Dokumente. Siehe
https://cdn1.scrivito.com/fokus/7da949d9a9b4817c/6362e72d82638adcf214e10cfbcd7a15/E-HEALTH_profil.pdf
Ausschnitt als Screen:
Am Screenshot oben sehen Sie wie persönliche Daten, wie z.B. die Versicherten-ID, in die sogenannten Tags/Informationselemente
von XML eingebettet sind.
Diese XML-Dokumente sind, wie die umfangreiche Schema_VSD.xsd selbst, direkt an die eGK und an den Einsatz der eGK, in den
Primärsystemen, im Zusammenspiel mit den geplanten Arbeitsabläufen, gebunden.
8
Ein für die Beurteilung der Gerichte wesentlicher Faktor ergibt sich zunächst aus der einfachen Betrachtung der Anzahl und des
Umfangs der beteiligten Dokumente, der darin enthaltenenen zusätzlichen Informationselemente und des genutzten einfachen
Prinzips der eingeschlossenen Verlinkung von einem Dokument in das nächste Dokument.
!
Das heißt in einem ersten Schritt muss für eine Beurteilung des erweiterten und erweiterbaren Datenumfangs der Versicherten der
vollständige Inhalt aller beteiligten XML- und XSD-Dokumente analysiert werden.
Was sich relativ einfach anhört ist in Wirklichkeit hochkomplex, denn es existieren weitere Faktoren, die den schon erweiterten
Datenumfang durch XML und XSD noch weiter aufblähen.
1.
Es existieren sehr viele Dokumente der Schemaressourcen (XML,XSD, WSDL) des neuen IT-Systems, die in verschiedenen Situationen
der Interaktionen zwischen Mensch, Geräten und System eine Rolle spielen und angesprochen werden.
2.
Es dürfen nicht nur die XML- und XSD Dokumente der Versicherten-eGK betrachtet werden, sondern die XML- und XSD-Dokumente
der Heilberufsausweise (HBA) der Ärzte und anderer Institutionen.
Dies hängt u.a damit zusammen, dass im späteren Ablauf in einen Terminal, eGK und HBA gleichzeitig gesteckt werden, der HBA
Zugriff auf die eGK erhält und beide Datenressourcen zusammenfassend re-kombiniert werden!
Die Grafik zeigt eines der geplanten Kartenlesegeräte in die eine eGK und ein HBA (HBC = Heilberufs-Card) gleichzeitig gesteckt
werden.
9
3.
Die XML/XSD-Daten müssen angesichts des riesigen Umfangs im neuen Deutschen Gesundheitssystem in ein Datenbank-System
überführt werden (bzw. -vorgehalten werden- je nach Art der Systemlösung, siehe Grafik Bereich Rechenzentren). Die fachlichen
Details dazu sind technisch sehr anspruchsvoll und können z.B. über folgenden Suchbegriff im Internet nachvollzogen werden:
Mapping zwischen XML und Datenbank. XML ist Text-basiert, von Menschen lesbar, Plattform-unabhängig und ein offener Standard.
Übersteigen die Anzahl und Größe der XML-Dateien die Grenzen der Verarbeitung überträgt man die Daten in ein großes
Datenbanksystem, damit sie effizient abgefragt werden können.
In fachlicher Hinsicht wird dies so beschrieben: Der Import von XML-Dokumenten in relationale Datenbanken erfordert einen
erheblichen Aufwand an Entwicklung und Anpassung. Zugleich wird er, um Abfragen auf Massen-XML-Daten effizent und zentralisiert
von vielen Anwendungen zu nutzen, zu einem unternehmenskritischen Prozess (Quelle/Autor: XML-Spektrum, http://www.sigsdatacom.de/sd/publications/js/2006/03/index.htm, Dr. -Ing. Helmut Knappe, ).
10
Der nachfolgende Screenshot zeigt exemplarisch wie einzelne Informationselemente (Daten), die in XML/XSD vorliegen, in eine
Datenbank überführt werden. Der Screenshot zeigt das Allora-Tool mit dem dieser Vorgang visualisiert werden kann.
XML/XSD
Mapping → → →
Datenbank (relational)
Bildquelle: Allora Tool für das Mapping zwischen XML/XSD Ressourcen und relationalen Datenbanken.
Selbst der IT-Laie kann erkennen, dass in der Datenbank rechts weitaus mehr Informations-Elemente existieren als in der XML/XSDQuelle auf der linken Seite. Dies beruht auf der Tatsache, dass wiederum die Steuerung und Zielsetzung der Datenvorhaltung in einer
großen Datenbank für die Produktion von XML weitere Informationslemente benötigt um die Daten eindeutig zu referenzieren und zu
11
beschreiben. Ausserdem ist es das erklärte Ziel dieser Lösung, wiederum mit den Daten aus der Datenbank, weitere Schritte der
Datenweiterverarbeitung für andere Bereiche des Gesundheitssystem zu realisieren.
!
Damit ist nun eines der größten Schwarzen Löcher des neuen Deutschen Gesundheitssystems benannt worden. Wir haben es hier mit
einem Datenmultiplikator zu tun der eine unvorstellbare Dimension besitzt, denn schließlich ist es das erklärte Ziel alle Datenquellen
und damit sind auch die existierenden Datenbanken im bestehenden Deutschen Gesundheitssystem gemeint, zu vernetzen.
Wir wissen dass diese Datenbanken existieren müssen und die Politik hat dieser Entwicklung einen Freibrief verpasst, ohne das
ausreichende Erkenntnisse darüber vorliegen wie hoch die Anzahl der Informationen und Datenelemente sein wird, die für die
Versicherten in jeder denkbaren Interaktion entstehen. Die Arbeitsweisen und Möglichkeiten, die sich daraus ergeben sind dem
Stuttgarter Gericht nicht bekannt.
Nach meinen Berechnungen können für jeden Versicherten eine riesige Anzahl erhoben werden, alleine bedingt durch das
Zusammenspiel der Schemaressourcen (XML, XSD, usw.) des eGK/TI-Systems.
Dazu bediene ich mich einer einfachen Berechnung, die sich aus den neuen Möglichkeiten der Auswertungen von Big Data ergeben.
Im Sinne der Auswertungsmöglichkeiten von Big Data darf jedes Informationselement zu einander kombiniert werden, egal ob dies
zunächst zu einem sinnvollen Ergebnis und Inhalt führt. Bei Big Data ist alles eine Rohdatenmenge, es wird zunächst keine Aussage
über die inhaltliche Qualität oder den Sinn der gesetzten Beziehung zwischen zwei Informationen getroffen.
Wenn beispielsweise 100 informelle Elemente in der Versicherten Schema_VSD.xsd und 100 informelle Elemente in den XSD-Files der
HBA enthalten sind, dann entstehen 100 x 100 potentielle Möglichkeiten der Re-Kombination der Informationselemente zueinander,
das sind in Summe
10000 Kombinationen von theoretischen Datenbeziehungen zueinander, die für einen Versicherten entstehen, in dem Moment wo eGK
und HBA gleichzeitig in ein Kartenlesegerät gesteckt werden
12
Wenn man nun die dargestellte Übertragung der 100 x 100 Elemente in die relationale Datenbank betrachtet und weitere 100
ergänzende Informationen dazukommen dann sind wir sehr schnell bei
1 000 000 Kombinationsmöglichkeiten von Informationen zueinander.
Diese Kombinationsmöglichkeiten können beliebig erweitert werden, wenn man die identifizierenden Merkmale berücksichtigt, die
konkret im neuen Deutschen Gesundheitssystem eingesetzt werden und dazu gehören die Identnummern der SmartCards, der
Kartenlesegeräte, der ID des Konnektors, der TelematiID, der OIDs, den Transaktionsprotokollen über Datum/Uhrzeit, usw. usw.
Die legitime Grundlage für meine Betrachtungsweise basiert u.a auf den neuen Möglichkeiten der Ontologien in der Informatik
https://de.wikipedia.org/wiki/Ontologie_(Informatik)
Informationselemente werden hier als Rohdatenmenge betrachtet die in einen Topf kommen und die dann mit Regeln in Beziehung
gesetzt werden. Die dafür erforderlichen Festlegungen der enthalten Inferenz- und Integritätsregeln, also Regeln zu
Schlussfolgerungen und zur Gewährleistung der Gültigkeit der potentiellen Beziehungen der Informationelemente zueinander sind hier
nicht Gegenstand der Betrachtung, denn es geht ausschließlich um die Vermittlung von Kenngrößen und der Dimension der
Datenproduktion im neuen System der elektronischen Gesundheitskarte und Telematik-Infrastruktur.
Und es geht um die Vermittlung der Sachverhalte an die Gerichte, damit diese erkennen, dass sie nicht so einfach wie bisher Urteile
aussprechen können.
Selbst wenn die erforderliche Festlegung der Beziehungsregeln für sinnvolle Schnittmengen zu einer Reduktion führen geht es ganz
sicher um tausende von Daten pro Versicherter die durch die Nutzung der elektronischen Gesundheitskarte im neuen IT-System in
großen Datenbanken landen werden.
13
Die Beurteilung des Stuttgarter Sozialgerichtes ist aus diesen Gründen vollkommen realitätsfremd:
1.
Für die Erhebung, Nutzung und Verarbeitung einer Reihe von sensiblen Daten ist die Einwilligung der Versicherten erforderlich; dies wird durch
verschiedene Regelungen zum Datenschutz und zu Maßnahmen zur Verhinderung missbräuchlicher Verwendung flankiert. Damit wird insgesamt
sichergestellt, dass der „gläserne Patient“ nicht Wirklichkeit wird.
2.
Angaben über spezialfachärztliche Versorgung u.a.) auf der Karte gespeichert werden sollen, dürfte dies nicht von der gesetzlichen Ermächtigung
gedeckt und unzulässig sein. Im vorliegenden Fall war der Versicherte jedoch von keinem dieser zusätzlichen Merkmale betroffen, weshalb er
nicht in seinen Rechten verletzt war.
Fazit zu 1./2.
!
Im Gegenteil mit dem System und den Möglichkeiten wird der Gläserne Bürger zur Realität und die Summe zusätzlicher informeller
Merkmale erzeugen eine unmittelbare Betroffenheit und Rechtsverletzung, die seinesgleichen sucht.
Die Gerichte sind nicht nur gezwungen technische Gutachter zu beauftragen um diese Sachverhalte aufzuklären. Nach den jetzigen
Erkenntnissen muss vor den Gerichten ausdrücklich beantragt werden die fehlenden Beschreibungen der Datenproduktion und
Datenbanksysteme von den Betreibern einzufordern!
!
Die gutachterliche Aufklärung und Visualisierung der Systematik muss mindestens für 4 Bereiche durchgeführt werden, die sich aus
dem Schema meiner Grafik ergeben:
14
Daraus ergeben sich folgende Aufgaben für die Anylse und Begutachtung des eGK/TI-Systems:
1. Analyse der XML/XSD Daten-Verarbeitung auf der eGK und dem HBA (Heilberufsausweis) im Kontext von Webservices und
Datenbanken
2. Analyse der XML/XSD Daten-Verarbeitung in den Rechenzentren und Datenbanksystemen und Klärung der Erweiterung des
Datenumfangs, bedingt durch das Mapping in ein relationales Datenbanksystem.
3. Analyse der erfolgten spezifischen Daten-Verarbeitung, die durch die Anpassung der Software verursacht wird, dazu gehört auch
die Analyse der Datenweiterverarbeitung in lokalen Datenbanken und externe Datenbanken der Softwareproduzenten.
4. Analyse der Weiterreichung von Daten aus den Bereichen 1-3 in andere periphere Bereiche des Gesundheitswesens und damit auch
automatisiert in die Cloud in den Big Data Pool
15
(Hinweis zu 4: In der befürwortenden Betrachtung des IT-Systems wird immer wieder betont, dass die getroffenen Maßnahmen für die Sicherheit
der Daten, z.B. über die Verschlüsselung der Daten der Versicherten, nicht im Internet (siehe Grafik oben 4) landen können. Diese Ansicht
entspricht nicht der Realität des Internet. Zwei einfache Beispiele sind die bekannten Vorgänge das Menschen, die in diesen sicheren Institutionen
arbeiten sich in Chats oder anderen Plattformen zu ihrer Arbeit äußern oder ihre Stellenbewerbungen im Internet veröffentlichen. In diese
Textaussagen, die dort entstehen fließen dann ungewollt und in indirekter Form Informationen, die aus der Mitte der sicheren Institutionen
stammen. Ein weiteres konkretes Beispiel sind die öffentlichen Stellenbewerbungen der gematik mbh Berlin und anderer Unternehmen, die das
neue Deutsche Gesundheitssystems aufbauen. Die Datenschützer können über diese öffentlichen Stellenbewerbungen dann Rückschlüsse ziehen
welche Technologien zum Einsatz kommen, mit denen die Telematik-Infrastruktur programmiert wird. Ein weiteres Beispiel sind Äußerungen und
Beiträge von kranken Menschen, die sich über ihre Krankheiten im Internet für die gegenseitige Unterstützung und Trostfindung austauschen. Hier
kann Google einen Suchalgorithmus programmieren, der alle diese spezifischen Informationen extrahiert, oder im Falle der sensibelsten und
schützenswertesten Daten des neuen Deutschen Gesundheitssystems können die darüber anonymisierten Datenbestände wiederum mit den
Daten im Internet abgeglichen werden! )
Da ausschließlich in der jetzigen Phase der juristischen Auseinandersetzung die Funktionalität und der Datenumfang auf der eGK der
derzeitigen Funktionalität priorisiert wird entsteht eine Situation für die Kläger die näher zu betrachten ist.
Unter Berücksichtigung meiner bisherigen Ausführungen gehören grundsätzlich die sensibelsten und schützenswertesten Daten nicht
in ein auf offenen Standards, Webservices, XML und XSD basierendes Datenaustausch-System.
An allen Ecken und Enden des neuen IT-Systems läßt sich das Ziel der überdimensionierten Datenerweiterung und der
automatisierten Weiterverarbeitung der Versichertendaten für kommerzielle Zwecke erkennen. Die Datensparsamkeit wird zur
Irreführung und Veräppelung der Bürger.
Die zusätzlichen Datencontainer für die Kapselung der eigentlichen Informationen erzeugen gewaltige Multiplikator-Effekte und
zusätzliche Informationen über die Information selbst, also Metadaten und sie ermöglichen die Nutzung der leeren Datencontainer für
die Erhebung von Negativ-Informationen.
Das heißt auch im Hinblick auf die nächsten Klageverfahren, dass die eGK in der jetzigen Ausprägung, noch ohne Online-Anbindung,
informell bereits deutlich erweitert wurde, denn die Elementnamen und die <xs:documentation> Abschnitte sind eigenständige
Informationen, die in vielfältigster Weise weiterverarbeitet werden. Es kann nicht sichergestellt werden, dass die eigenständigen
Informationslemente mit der Versicherungsnummer und anderen Elementen übergreifend verknüpft werden. Die Anlage der leeren
Datencontainer ermöglicht zudem die Erhebung von Negativ-Informationen (oder auch Zeroinformationen), denn die fehlenden
16
Angaben führen zu einer aussagekräftigen Zero-Information, siehe z.B. in der Schema_VSD.xsd der eGK:
1.
0 = aerztlicher Selektivvertrag liegt nicht vor
2.
0 (false) = keine Kostenerstattung fuer aerztliche Versorgung
3.
<xs:element name="BesonderePersonengruppe" type="VSD:codeDigits" minOccurs="0">
4.
<xs:element name="DMP_Kennzeichnung" type="VSD:codeDigits" minOccurs="0">
Zero – Informationsaussagen mit Aussagekraft (a) ohne eingeholte Zustimmung der Versicherten:
1. aerztlicher Selektivvertrag liegt nicht vor
2. keine Kostenerstattung fuer aerztliche Versorgung
3. keine Zuordnung zu besonderen Personengruppen
4. keine Zuordnung zur DMP-Kennzeichnung
Für die enthaltenenen ZERO. Bzw. Negativ-Informationen wurde keine Zustimmung bei den Versicherten eingeholt, dies widerspricht
in deutlicher Form der Annahme in dem Urteil, dass
..“das Erheben, Verarbeiten und Nutzen von Daten zu diesem Zweck nur mit der Einwilligung der Versicherten gestattet ist und
unbestimmte Rechtsbegriffe wie zB der Begriff "Versichertenstatus" nicht durch (normsetzende) Vereinbarungen im Range unterhalb
des Parlamentsgesetzes ausgefüllt und "datenmäßig erweitert" werden.“
Die 4 bespielhaften Datencontainer (a) stellen nur einen geringfügigen Ausschnitt des Umfangs von mehreren tausend dieser
Informationslemente dar, die normsetzende Vereinbarungen unterhalb des Parlamentsgesetzes erzeugen und sie wandern in
unüberschaubaren Form in die Rechenzentren und Softwareanwendungen der Primärsysteme und können von dort aus weiter mit
anderen Daten verknüpft werden.
Jedes dieser Informationselemente kann, ohne unsere Kontrolle und ohne Kontrolle der Landesdatenschutzbeauftragten,
17
mit
anderen Informationselementen und Informationsquellen verknüpft werden.
Die Verkettung einiger XML/XSD-Dokumente, ausschließlich bezogen auf die elektronische Gesundheitskarte (eGK) und die
Heilberufsausweise (HBA) kann schematisch so dargestellt werden.
Schema_VSD.xsd > gematik_Pers_HBA.xsd > include gematik_HBA_SMC-B_Typen.xsd > include gematik_HBA_SMC-B_Keys.xsd
18
Die vier exemplarisch gezeigten Dateien
•
Schema_VSD.xsd
•
gematik_Pers_HBA.xsd
•
gematik_HBA_SMC-B_Typen.xsd
•
gematik_HBA_SMC-B_Keys.xsd
sind Teil der Schemaressourcen des gesamten Systems für die Datenverarbeitung und den Transport der Daten, die aus 24 Ordnern
und 72 Dateien des Typs *.xsd, *.xsl und *.wsdl bestehen.
19
Der Seitenumfang dieser Erweiterungen und Anweisungen und die darin enthaltene Menge der Informationselemente (Tags) ist
unglaublich groß. Die größte XSD-Datei die voc.xsd besteht aus 280 DINA4 Seiten (Schriftgröße 10) und hunderten Tags.
Hier ein vollständige Übersicht aller enthaltenen Files für die Datenweiterverarbeitung:
20
In einer Datei aus den Schemaressourcen, der poc.xsd sind z.B. Elemente enthalten, die es ermöglichen rassische und ethnische
Informationen zu erheben, was gegen das BDSG verstößt. Im BDSG wurde 2001 die neue Kategorie der besonderen Arten
personenbezogener Daten eingeführt. Dies sind "Angaben über die rassische und ethnische Herkunft, politische Meinungen,
religiöse oder philosophische Überzeugungen, Gewerkschaftszugehörigkeit, Gesundheit oder Sexualleben" (Art. 8 Abs. 1 EU-DSRL,
§ 3 Abs. 9 BDSG, § 11 Abs. 3 LDSG SH). Dies ist nur ein Beispiel der den Gerichten unbekannten und weitreichenden Möglichkeiten
des IT-Systems.
Die Auswertung dieser Ressourcen führt zu einem recht vollständigen Bild der Funktionsweisen des eGK/TI-Systems.
Das Urteil des Landessozialgerichts Stuttgart vom 21.06.2016, Az. L11 KR 2510/15 steht hierzu in einem krassen und unwirklichen
Widerspruch:
1
Der Umstand, dass die eGK geeignet sein muss, die in § 291a Abs 3 SGB V aufgeführten Anwendungen zu unterstützen, führt nicht
zu einem Verstoß gegen das Recht auf informationelle Selbstbestimmung der Versicherten, da das Erheben, Verarbeiten und Nutzen
von
Daten
zu
diesem
Zweck
nur
mit
der
Einwilligung
der
Versicherten
gestattet
ist.
2
Die eGK darf ohne Einwilligung des Versicherten nur die in § 291a Abs 1 SGB V genannten Daten enthalten. Unbestimmte
Rechtsbegriffe wie zB der Begriff "Versichertenstatus" dürfen nicht durch (normsetzende) Vereinbarungen im Range unterhalb des
Parlamentsgesetzes ausgefüllt und "datenmäßig erweitert" werden.
]
Der gläserne Mensch wird Wirklichkeit in dem mit 72 Dateien und den darin enthaltenen tausenden Definitionen, Anweisungen und
Merkmalen, die sensibelsten und schützenswertesten Daten der Versicherten verarbeitet, „datenmäßig“ erweitert und transportiert
werden.
21
Tausende von zusätzlichen Merkmalen stehen bereit um nicht nur Betroffenheit auszulösen, sondern die gläsern gewordenen
Menschen zur informationellen Verwertungsmasse werden zu lassen.
Die Ausführungen des Gerichtes in seinen Entscheidungsgründen
24
„Ein Anspruch auf Befreiung von der Verwendung der elektronischen Gesundheitskarte besteht nicht. Jeder Versicherte ist grundsätzlich verpflichtet, die
elektronische Gesundheitskarte zu nutzen. Das Recht auf informationelle Selbstbestimmung gewährt kein Recht auf Verhinderung der Digitalisierung und
„Weiterleben in einer analogen Welt“.
ist unmittelbarer Ausdruck vollständiger fehlender Sorgfalt das System der elektronischen Gesundheitskarte und Telematikinfrastruktur aufzuklären.
Die vorliegenden Ausführungen und letztlich die Klage des Klägers beinhalten nicht eine verallgemeinerte Verhinderung
der Digitalisierung und Beibehaltung analoger Welten.
Es geht vielmehr darum Aufklärung zu ermöglichen, Konsequenzen aufzuzeigen um zu anderen digitalen Lösungen und
Systemen zu gelangen, die nicht dieses orwellsche Monopolsystem einer zukünftig zu 100% überwachten Gesellschaft
erschafft.
Die Ausführungen des Gerichtes in seinen Entscheidungsgründen, siehe 30 und 31
[
30
Nach § 291 Abs 3 Satz 1 SGB V muss die eGK geeignet sein, folgende Anwendungen zu unterstützen, insbesondere das Erheben, Verarbeiten und
Nutzen von
22
(1.) medizinischen Daten, soweit sie für die Notfallversorgung erforderlich sind,
(2.) Befunden, Diagnosen, Therapieempfehlungen sowie Behandlungsberichten in elektronischer und maschinell verwertbarer Form für eine
einrichtungsübergreifende, fallbezogene Kooperation (elektronischer Arztbrief),
(3.) Daten zur Prüfung der Arzneimitteltherapiesicherheit,
(4.) Daten über Befunde, Diagnosen, Therapiemaßnahmen, Behandlungsberichte sowie Impfungen für eine fall- und einrichtungsübergreifende
Dokumentation über den Patienten (elektronische Patientenakte),
(5.) durch von Versicherten selbst oder für sie zur Verfügung gestellte Daten,
(6.) Daten über in Anspruch genommene Leistungen und deren vorläufige Kosten für die Versicherten (§ 305 Abs 2),
(7.) Erklärungen der Versicherten zur Organ- und Gewebespende,
(8.)
Hinweisen der Versicherten auf das Vorhandensein und den Aufbewahrungsort von Erklärungen zur Organ- und Gewebespende sowie (9.)
Hinweisen der Versicherten auf das Vorhandensein und den Aufbewahrungsort von Vorsorgevollmachten oder Patientenverfügungen nach § 1901a des
Bürgerlichen Gesetzbuchs.
31
Indes ist die Erhebung, Nutzung und Verarbeitung dieser Daten nur zulässig, wenn der Versicherte einwilligt (§ 291a Abs 3 Satz 4 und Abs 5 S 1 SGB V),
wobei die Einwilligung jederzeit widerrufen werden kann (§ 291a Abs 3 Satz 5 SGB V). Der Kläger kann damit schon durch die Verweigerung seiner
Einwilligung verhindern, dass entsprechende Daten überhaupt erst erhoben werden.
]
weist darauf hin dass die Erhebung, Nutzung und Verarbeitung dieser Daten nur zulässig ist wenn der Versicherte einwilligt.
Die Frage lautet wie die Ablehnung umgesetzt werden soll, wenn eines der größten IT-Systeme der Welt, Teil einer komplexen
Infrastruktur des bestehenden Deutschen Gesundheitswesens und einer bereits digitalisierten eHealth-Infrastruktur, an allen Ecken
und Enden der interaktiven Schnittstellen der Datenerfassung personenbeziehbare und identifizierende Informationen erhebt und
diese in automatisierte Form, über die beschriebenen Methoden und Technologien über Software und Hardware, transportiert und in
23
Rechenzentren und Datenbanken weiterverarbeitet.
An dieser Stelle muss erneut betont werden, das neue Deutsche Gesundheitssystem ist, trotz aller verfügbaren Informationen, nicht
ausreichend analysiert und visualisiert um das wahre Ausmaß der Gefährdung der Bürger und der Gesellschaft vollständig zu
erfassen. Ein derart großes IT-Projekt setzt auch dafür dann vollkommen neue Maßstäbe und erfordert Finanzierungsmittel in
Millionenhöhe. Ein weiterer anerkannter Aspekt in der Informatik ist, dass es zur Zeit noch keine ausreichenden Methoden und
Konzepte der Visualisierung und Ermittlung der Interaktivität aller Komponenten eines IT-Systems in diesem Umfang gibt. Dies hätte
man zunächst für das Projekt im Vorfeld entwickeln müssen.
Welche gewaltigen Möglichkeiten stecken in einem IT-System für ein ganzes Land für das 11 Milliarden Transaktionen und einem
Datenaufkommen mit mindestens 26,3 Terabyte pro Jahr (ohne Bildaten) erwartet werden. Die Digitalisierung der medizinischen
Versorgung in Deutschland gehört damit zu den anspruchsvollsten IT-Projekten der Welt und damit zu einem gesellschaftlichen
System mit dem größtmöglichen denkbaren Gefährdungspotential.
Die angeblich ausreichenden Maßnahmen der Sicherung der Freiwilligkeit, in einem in Wirklichkeit vollkommen intransparenten
System, das angeblich nicht den gläsernen Bürger erzeugt, ist nicht mehr als eine Beruhigungspille, die das Hirn vernebelt.
Das Setzen eines Merkmals, letztlich einer identifizierenden Information mit Aussage, heisst ja nur, dass in technischer Hinsicht, die
Informationen der freiwilligen Anwendungen unterdrückt werden. Damit ist aber nicht deren Erhebung verhindert, wenn man die
gewonnenen Erkenntnisse berücksichtigt, von denen hier berichtet wird.
Die Ziele der Politik und Befürworter des neuen eGK/TI-Systems sind die uneingeschränkte Interoperabilität. Es soll eine Offenheit der
Telematik-Infrastruktur für eHealth-Anwendungen entstehen, Anwendungen (Software/ Medizingeräte) sollen miteinander
kommunizieren können, der Datenfluss gewährleistet und ein Interoperabilitätsverzeichnis für die öffentliche Nutzung entstehen.
Ich zitiere aus dem Online frei zugänglichen Artikel von Harald G. Schweim, der zitiert werden darf mit folgenden Angaben:
24
[
Schweim HG. Die unerträgliche Geschichte der Gesundheitskarte in Deutschland. GMS Med Inform Biom Epidemiol. 2007;3(1):Doc04.
©2007 Schweim; licensee GMS Medizinische Informatik, Biometrie und Epidemiologie. This is an Open Access article: verbatim copying and redistribution of this
article is permitted in all media for any purpose, provided this notice is preserved with the article's original URL. Artikel online frei zugänglich unter
http://www.egms.de/en/journals/mibe/2007-3/mibe000052.shtml
]
Auszüge aus seiner Kurzmitteilung:
[
„Die e-GK ist nur Teil einer komplexen Infrastruktur. Weitere wesentliche Bausteine sind der elektronische Heilberufsausweis (HPC),
mit dem sich Ärzte und Apotheker beim Zugriff auf medizinische Daten ausweisen, ein Kommunikationsnetz, das 123.000
niedergelassene Ärzte, 65.000 Zahnärzte, 2200 Krankenhäuser, 21.000 Apotheken und rund 270 Krankenkassen miteinander
vernetzt sowie die zugehörigen Netzwerksserver.“
und weiter:
„Seit 01.01.2006 hätten 71 Millionen GKV-Versicherte ihre Karte erhalten müssen, auf denen zunächst nur die Grunddaten stehen,
auf die dann aber mindestens bei 12 Millionen Versicherten die möglicherweise lebensrettenden Notfalldaten aufgebracht werden
sollen.
Mit 890 Millionen e-Rezepten pro Jahr soll sich das Kartenprojekt in wenigen Jahren durch die erzielten Einsparungen im
Gesundheitswesen amortisieren. Etwa ab 2012 sollten nach Angaben des bIT4Health-Konsortiums jährlich 350 Millionen e-Arztbriefe
und 1,24 Milliarden e-Patientenakten über die Gesundheitskarte abgewickelt werden. Auf diese Patientenakten soll der mündige
Patient Zugriff haben, entweder nach dem 4-Augen-Prinzip beim Arzt oder über eine Datenbankabfrage, für die er zusätzlich eine
qualifizierte digitale Signatur besitzen muss.“
und weiter:
„Vom Start weg müsste das System Millionen von Anfragen der Apotheker und Ärzte verkraften können. Allein das e-Rezept sorgt
dafür, dass tagsüber 8500 Zugriffe in der Minute erfolgen, was eine extrem leistungsfähige Backend-Struktur voraussetze. Bislang
gibt es wenig mehr als die Einschätzung von IT-Experten, die für Deutschland von einer Installation
ausgehen, die um den Faktor Sieben größer als das österreichische System ausfällt, das auf 10 Millionen Karten ausgelegt ist. Der
25
Informatiker Paul Schmücker machte auf eine
"vergessene" Dimension der Gesundheitskarte, die Langzeitarchivierung medizinischer Daten über mindestens 30 Jahre hinweg,
aufmerksam. Allein in den Krankenhäusern werde pro Jahr und Bett ein laufender Meter an Dokumentationsakten produziert.
Zusammen mit den Arztbriefen und den Dokumentationen derÄrzte seien dies 2,2 Milliarden Dokumente jährlich, die langfristig
aufbewahrt werden müssten, während Schlüsselalgorithmen und Zertifikate kurzfristig verfallen können.“
]
Diese Kurzmitteilung ist 2006 entstanden, es sind also 10 Jahre vergangen und das neue Deutsche Gesundheitssystem konnte bisher
nicht in dieser beschriebenen Form umgesetzt werden. Die zitierten Inhalte dienen dem Zweck erneut auf die gewaltige Dimension
dieses Vorhabens aufmerksam zu machen und darauf, dass die Gerichte die daraus zu gewinnenden Erkenntnisse, die bereits damals
existiert haben, ebenso nicht berücksichtigen, wie neuere Erkenntnisse.
Aus der Gegenüberstellung einer weiteren Begründung des eGK-Urteils vom 21.06.2016, Az. L11 KR 2510/15, Abschnitt 38
38
Soweit der Kläger sich schon heute durch die künftigen in § 291a Abs 3 Satz 1 SGB V vorgesehenen Anwendungsmöglichkeiten der eGK in eigenen
Rechten verletzt sieht und in Verbindung mit der Versichertennummer (§ 291 Abs 2 Nr 6 SGB V) den „gläsernen Patienten“ befürchtet, teilt der Senat
diese Auffassung nicht. Bei den Anwendungsmöglichkeiten nach § 291a Abs 3 Satz 1 SGBV handelt es sich nicht um die Pflichtangaben der
eGK, sondern um eine vom Gesetz vorgesehene Möglichkeit, auf freiwilliger Basis über die rein administrative Funktion der eGK
Datenanwendungsmöglichkeiten zu nutzen. Bereits das Erheben als auch das Verarbeiten und Nutzen von Daten mittels der eGK ist in den Fällen
des § 291a Abs 3 Satz 1 SGB V nur mit dem Einverständnis der Versicherten zulässig (§ 291a Abs 5 Satz 1 SGB V, vgl dazu Dochow WzS 2015, 137,
144). Dafür, dass trotz Fehlens seines Einverständnisses mit seiner eGK fakultative Daten erhoben, verarbeitet oder genutzt werden, ist nichts
ersichtlich. Eine Rechtsverletzung des Klägers ist diesbezüglich jedenfalls derzeit ausgeschlossen, eine verfassungsrechtliche Überprüfung erübrigt sich.
Selbst wenn bei fehlender Einwilligung im Einzelfall medizinische Daten rechtswidrig gespeichert würden, könnten Ärzte oder Dritte hiervon weitgehend
keinen Gebrauch machen (BSG 18.11.2014, B 1 KR 35/13 R Rn 22).
26
lassen sich nun folgende wichtige Rückschlüsse ziehen:
Die Beurteilung übersieht, dass die Ausgestaltung der administrativen Funktionen bereits in ihrer grundlegenden Konstruktion,
eingebettet in die XML/XSD-Verarbeitung auf der eGK der derzeitigen Funktionalität, einen nicht freiwilligen erweiterten Datenbestand
erzeugt, der keinerlei Zustimmungsverfahren und Clearingstelle unterliegt. Die Unterscheidung von Pflichtangaben und
Anwendungsmöglichkeiten ist eine Klassifizierung, die von Betreibern und Entwicklern des Systems vorgegeben wurde, aber nie einer
unabhängigen Überprüfung unterzogen wurde. Das für das Gericht nichts ersichtlich ist für das Erheben fakultativer Daten, wenn das
Gericht im gleichen Urteil als Leitsatz feststellt:
„Die eGK darf ohne Einwilligung des Versicherten nur die in § 291a Abs 1 SGB V genannten Daten enthalten. Unbestimmte
Rechtsbegriffe wie zB der Begriff "Versichertenstatus" dürfen nicht durch (normsetzende) Vereinbarungen im Range unterhalb des
Parlamentsgesetzes ausgefüllt und "datenmäßig erweitert" werden.“
ist unlogisch, da bereits hier erste Hinweise für Daten vorliegen und bestätigt sind, die ohne Einwilligung des Versicherten als
erweiterbare Datencontainer auf der eGK existieren.
Schlußwort
Dieser Artikel zeigt die Unmöglichkeit für die Gerichte auf die systemischen Sachverhalte und ihre Folgen für die Bürger in
ausreichender Form zu beurteilen. Nur mit Hilfe technischer Gutachter und Anträge auf Einholung der fehlenden Informationen, z.B.
für die xml-orientierten Datenbankanwendungen und Softwareanpassungen in den Primärsystemen, kann eine ausreichende
Aufklärung und Beurteilung auf den Weg gebracht werden. Es kann zum jetzigen Zeitpunkt nicht ausgeschlossen werden, dass für die
Aushändigung der eGK bereits erste Datensätze der Versicherten in der Systematik der Telematik-Infrastruktur entstehen, die nicht
durch die gesetzlichen Grundlagen in ausreichender Form gedeckt sind.
27
Die nachfolgende Schema_VSD.xsd, aufgeführt mit all ihren Informationselementen, ist die verfügbare Quelle für die Existenz der
erhobenenen Informationen auf der eGK, aber sie kann nicht in jeder Hinsicht als die einzige aussagekräftige Quelle der
Datenerfassung betrachtet werden. Da erwiesenermaßen eGK und HBA zusammengesteckt werden, muss das Zusammenspiel der
dafür existierenden XSD-Ressourcen für den Heilberufsausweis der Ärzte mit der eGK weiter untersucht werden. Es entstehen enorme
Auswirkungen, konkret für das Arzt-Patientenverhältnis und für die Entstehung des gläsernen Menschen, wenn beispielsweise weitere
nicht durch Normierung erfasste Elemente, wie die TelematikID im HBA, also einem bisher nicht näher untersuchten
Informationselement, mit identifizierenden numerischen Merkmalen, dem eGK-Datensatz hinzugefügt werden können!
Im Anhang finden Sie die Liste der Informationslemente der Schema_VSD.xsd, bereits befreit von einigen Elementen um die
Lesbarkeit für Sie zu steigern und die einzelnen besser lesbaren Screenshots der verketteten XSD-Ressourcen für die Erweiterung der
Daten, die Heilberufsausweise betreffen.
Oberrieden, 24.07.2016
Rolf D. Lenkewitz
Anhang 1 und 2
28
1
Ausgangsbasis des eGK-Datensatzes ist der minimalste Ansatz der Datenbetrachtung der Schema_VSD.xsd die nachfolgend in etwas
übersichtlicher und freier Form erfolgt.
<xs:element name="Versicherter">
<xs:element name="Versicherungsschutz">
<xs:documentation>Es handelt sich um eine Pflichtangabe.</xs:documentation>
<xs:element name="Beginn" type="VSD:ISO8601Date">
<xs:documentation>Gibt den Beginn des Versicherungsschutzes (hier: Leistungsanspruch) des Versicherten bei dem unter Klasse Kostentraeger angegebenen Kostentraeger an. </xs:documentation>
<xs:element name="Ende" type="VSD:ISO8601Date" minOccurs="0">
<xs:documentation>Gibt das Datum des Endes der Mitgliedschaft des Versicherten bei dem unter Klasse Kostentraeger angegebenen Kostentraeger an oder das Datum des Fristablaufs bei befristeter Gueltigkeit der Karte.
Dieses Feld ist ausschließlich für das beschriebene Datum zu nutzen (gemäß § 291 SGB V).</xs:documentation>
<xs:element name="Kostentraeger">
<xs:extension base="VSD:Kostentraeger">
<xs:element name="AbrechnenderKostentraeger" type="VSD:Kostentraeger" minOccurs="0"/>
<xs:element name="Zusatzinfos">
<xs:element name="ZusatzinfosGKV">
<xs:element name="Versichertenart" type="VSD:codedString">
<xs:documentation>Gibt die Versichertenart des Versicherten an.
1 = Mitglied,
3 = Familienversicherter,
5 = Rentner und ihre Familienangehörigen
</xs:documentation>
<xs:element name="Zusatzinfos_Abrechnung_GKV">
<xs:element name="Kostenerstattung" minOccurs="0">
<xs:documentation>Gibt an, ob der Kostentraeger den Nachweis der Inanspruchnahme von Leistungen der Abrechnungsart Kostenerstattung auf der eGK speichert.
vorhanden = Nachweis wird genutzt;
nichtvorhanden = Nachweis wird nicht genutzt</xs:documentation>
<xs:element name="AerztlicheVersorgung" type="VSD:boolean">
<xs:documentation>Gibt die vom Versicherten gewaehlte Kostenerstattung fuer die aerztliche Versorgung an.
1 (true) = Kostenerstattung fuer aerztliche Versorgung
0 (false) = keine Kostenerstattung fuer aerztliche Versorgung</xs:documentation>
<xs:element name="ZahnaerztlicheVersorgung" type="VSD:boolean">
<xs:annotation>
<xs:documentation>Gibt die vom Versicherten gewaehlte Kostenerstattung fuer zahnaerztliche Versorgung an.
1 (true) = Kostenerstattung fuer zahnaerztliche Versorgung
0 (false) = keine Kostenerstattung fuer zahnaerztliche Versorgung</xs:documentation>
<xs:element name="StationaererBereich" type="VSD:boolean">
<xs:documentation>Gibt die vom Versicherten gewaehlte Kostenerstattung fuer den stationaeren Bereich an.
1 (true) = Kostenerstattung fuer stationaeren Bereich
0 (false) = keine Kostenerstattung fuer stationaeren Bereich </xs:documentation>
<xs:element name="VeranlassteLeistungen" type="VSD:boolean">
<xs:documentation>Gibt die vom Versicherten gewaehlte Kostenerstattung fuer veranlasste Leistungen an.
1 (true) = Kostenerstattung fuer veranlasste Leistungen
29
0 (false) = keine Kostenerstattung fuer veranlasste Leistungen</xs:documentation>
<xs:element name="WOP" type="VSD:numberWithLeadingZero">
<xs:annotation>
<xs:documentation>Das Kennzeichen WOP ist gemaess § 2 Abs. 2 der Vereinbarung zur Festsetzung des Durchschnittsbetrages gemaess Artikel 2 § 2 Abs. 2 des Gesetzes zur Einfuehrung des Wohnortprinzips bei
Honorarvereinbarungen fuer Aerzte und Zahnaerzte und zur Krankenversichertenkarte gemaess § 291 Abs. 2 Fuenftes Sozialgesetzbuch (SGB V) erforderlich.
01 = Schleswig-Holstein
02 = Hamburg
03 = Bremen
17 = Niedersachsen
20 = Westfalen-Lippe
38 = Nordrhein
46 = Hessen
51 = Rheinland-Pfalz
52 = Baden-Württemberg
71 = Bayern
72 = Berlin
73 = Saarland
78 = Mecklenburg-Vorpommern
83 = Brandenburg
88 = Sachsen-Anhalt
93 = Thüringen
98 = Sachsen
Gemäß Anlage 21 BMV-Ä und EKV.</xs:documentation>
<xs:attribute name="CDM_VERSION" type="VSD:CDMVersion" use="required"/>
<xs:element name="UC_PersoenlicheVersichertendatenXML">
<xs:element name="Versicherter">
<xs:element name="Versicherten_ID" type="VSD:insurantId">
<xs:documentation>Die Versicherten-ID ist der 10-stellige unveraenderliche Teil der 30-stelligen Krankenversichertennummer.</xs:documentation>
<xs:element name="Person">
<xs:element name="Geburtsdatum" type="VSD:ISO8601Date">
<xs:documentation>Gibt das Geburtsdatum des Versicherten an.
Hinweis: Das Geburtsjahr MUSS immer gefuellt werden. Bei Inlaendern ist immer ein logisch richtiges Geburtsdatum anzugeben. Bei Auslaendern gilt folgendes: Zumindest das Geburtsjahr ist immer anzugeben. Im Geburtstag
oder im Geburtstag und im Geburtsmonat ist bei Ausländern „00“ bzw. „0000“ zulässig, wenn der Geburtstag und der Geburtsmonat nicht zu ermitteln sind.</xs:documentation>
<xs:element name="Vorname">
<xs:documentation>Gibt den Vornamen der Person an.
Alle Vornamen der Person (max. 5) werden eingegeben. Mehrere Vornamen werden durch Leerzzeichen oder Bindestrich getrennt.</xs:documentation>
<xs:restriction base="VSD:name">
<xs:element name="Nachname">
<xs:documentation>Gibt den Nachnamen der Person an.</xs:documentation>
<xs:restriction base="VSD:name">
<xs:element name="Geschlecht" type="VSD:gender">
<xs:documentation>Gibt das Geschlecht des Versicherten an. ("M" = maennlich, "W" = weiblich).</xs:documentation>
<xs:element name="Vorsatzwort" type="VSD:nameExtension" minOccurs="0">
<xs:documentation>Gibt die Vorsatzwoerter der Person an.
Mehrere Vorsatzwörter werden durch Leerzeichen getrennt angegeben.
Anlage 6 (Tabelle der gültigen Vorsatzworte) zur DEÜV, V 2.30 vom 8.08.07.</xs:documentation>
<xs:element name="Namenszusatz" type="VSD:nameExtension" minOccurs="0">
<xs:documentation>Gibt die Namenszusaetze der Person an, z. B.: Freiherr
Mehrere Namenzusätze werden durch Leerzeichen getrennt angegeben.
Anlage 7 (Tabelle der gültigen Namenszusätze) zur DEÜV, V 2.25 vom 4.05.06.</xs:documentation>
30
<xs:element name="Titel" type="VSD:nameExtension" minOccurs="0">
<xs:documentation>Gibt die akademischen Grade der Person an.
Mehrere Titel werden durch Leerzeichen getrennt angegeben.</xs:documentation>
<xs:element name="PostfachAdresse" minOccurs="0">
<xs:element name="Postleitzahl" minOccurs="0">
<xs:documentation>Gibt die Postleitzahl der Strassen- oder Postfachadresse an. Die Befüllung des Feldes Postleitzahl erfolgt gemäß den Festlegungen der DEÜV. In Verbindung mit dem Wohnsitzländercode "D" für Deutschland
MUSS die
Postleitzahl 5-stellig numerisch sein. Soweit Angaben zur Adresse und zum Postfach gemacht werden, MUSS die Postleitzahl zu beiden Adressdaten vorhanden sein. Bei Anschriften ohne Postleitzahl wird das Feld nicht
verwendet.</xs:documentation>
<xs:element name="Ort">
<xs:annotation>
<xs:documentation>Gibt den Ort zur Strassen- und oder Postfachadresse an.
Soweit Angaben zur Adresse und zum Postfach gemacht werden, MUSS der Ort zu beiden Adressdaten vorhanden sein.
Abweichung zur Festlegung in DEÜV (Feldlänge = 34)</xs:documentation>
<xs:element name="Postfach">
<xs:documentation>Gibt das Postfach der Person an.</xs:documentation>
<xs:element name="Land" type="VSD:LandType"/>
<xs:element name="StrassenAdresse" minOccurs="0">
<xs:element name="Postleitzahl" minOccurs="0">
<xs:documentation>Gibt die Postleitzahl der Strassen- oder Postfachadresse an. Die Befüllung des Feldes Postleitzahl erfolgt gemäß den Festlegungen der DEÜV. In Verbindung mit dem Wohnsitzländercode "D" für Deutschland
MUSS die
Postleitzahl 5-stellig numerisch sein. Soweit Angaben zur Adresse und zum Postfach gemacht werden, MUSS die Postleitzahl zu beiden Adressdaten vorhanden sein. Bei Anschriften ohne Postleitzahl wird das Feld nicht
verwendet.</xs:documentation>
<xs:element name="Ort">
<xs:documentation>Gibt den Ort zur Strassen- und oder Postfachadresse an.
Soweit Angaben zur Adresse und zum Postfach gemacht werden, MUSS der Ort zu beiden Adressdaten vorhanden sein.
Abweichung zur Festlegung in DEÜV (Feldlänge = 34)</xs:documentation>
<xs:element name="Land" type="VSD:LandType"/>
<xs:element name="Strasse" minOccurs="0">
<xs:annotation>
<xs:documentation>Gibt den Namen der Strasse an.
Wenn die Hausnummer nicht separat abgelegt werden kann, ist es zulässig, die Hausnummer in das Feld Straße zu übernehmen. Anlage 9.4 (Datensätze und Datenbausteine sowie Fehlerkatalog) zur DEÜV, V 2.39 vom 25.11.09</
xs:documentation>
<xs:element name="Hausnummer" minOccurs="0">
<xs:documentation>Gibt die Hausnummer in der Strasse der Person an. Pflichtangabe soweit bekannt, wenn die Hausnummer nicht separat abgelegt werden kann, ist es zulässig, die Hausnummer in das Feld Straße zu
übernehmen.
Anlage 9.4 (Datensätze und Datenbausteine sowie Fehlerkatalog) zur DEÜV, V 2.39 vom 25.11.09</xs:documentation>
<xs:element name="Anschriftenzusatz" minOccurs="0">
<xs:annotation>
<xs:documentation>Gibt die relevanten Zusaetze zur Anschrift an. Als Anschriftenzusatz kann z. B. „Hinterhaus“ angegeben werden.</xs:documentation>
<xs:attribute name="CDM_VERSION" type="VSD:CDMVersion" use="required"/>
<xs:element name="UC_GeschuetzteVersichertendatenXML">
<xs:element name="Zuzahlungsstatus">
<xs:documentation>Es handelt sich um eine Pflichtangabe fuer GKV. Hinweis: Dieses Datenfeld ist nicht frei auslesbar, sondern nur berechtigten Personen zugaenglich.</xs:documentation>
<xs:element name="Status" type="VSD:booleanInteger">
<xs:documentation>Gibt an, ob fuer den Versicherten eine Befreiung von der Zuzahlungspflicht nach § 62 SGB V vorliegt.
Hinweis: "Fuer eine befristete Uebergangszeit (die Frist ist noch festzulegen) wird bei der eGK der schuetzenswerte Teil der Versichertenstammdaten in derselben Form so in den ungeschuetzten Container kopiert, dass der
gesamte, ohne Zusatzauthentifizierung auslesbare Versichertendatensatz inhaltlich dem der heutigen KVK entspricht." [Archboard 33]
1 (true) = von Zuzahlungspflicht befreit
0 (false) = von Zuzahlungspflicht nicht befreit (Standard)</xs:documentation>
31
<xs:element name="Gueltig_bis" type="VSD:ISO8601Date" minOccurs="0">
<xs:documentation>Gibt die Gueltigkeit der Befreiung von der Zuzahlungspflicht nach § 62 SGB V an.
Dieses Datenobjekt ist erforderlich, um im Hinblick auf die Online-Aktualisierung ein „Massen-Update" des Zuzahlungsstatus zum Jahreswechsel zu entzerren. Wird nur angegeben, wenn Status Zuzahlung mit 1 (= befreit)
angegeben ist.
</xs:documentation>
<xs:element name="BesonderePersonengruppe" type="VSD:codeDigits" minOccurs="0">
<xs:documentation>Gibt die Zugehoerigkeit des Versicherten zu einer besonderen Personengruppe an. Die Kennzeichnung erfolgt gemaess der Schluesseltabelle.
4 = BSHG (Bundessozialhilfegesetz) § 264 SGB V,
6 = BVG (Gesetz über die Versorgung der Opfer des Krieges),
7 = SVA-Kennzeichnung für zwischenstaatliches Krankenversicherungsrecht: - Personen mit Wohnsitz im
Inland, Abrechnung nach Aufwand,
8 = SVA-Kennzeichnung, pauschal.
</xs:documentation>
<xs:element name="DMP_Kennzeichnung" type="VSD:codeDigits" minOccurs="0">
<xs:documentation>Gibt die Teilnahme des Versicherten an einem Disease Management Program an. Die Kennzeichnung erfolgt gemaess der Schluesseltabelle.
1 = Diabetes mellitus Typ 2,
2 = Brustkrebs,
3 = Koronare Herzkrankheit,
4 = Diabetes mellitus Typ 1,
5 = Asthma bronchiale,
6 = COPD (chronic obstructive pulmonary disease)
Das DMP-Kennzeichen findet derzeit aufgrund bilateraler vertraglicher Verpflichtungen von einzelnen Kostenträgern und Leistungserbringern noch Verwendung. Zur Abbildung dieser Verträge zu Disease-Management-Programmen
kann das DMP-Kennzeichen weiterhin gemäß §291 Abs. 2a Satz 3 SGB V auf der eGK gespeichert werden, da es sich dabei um Angaben nach § 53 SGB V bzw. Angaben zum Nachweis von zusätzlichen Vertragsverhältnissen
handelt.</xs:documentation>
<xs:element name="Selektivvertraege">
<xs:element name="Aerztlich" type="VSD:codeDigit">
<xs:documentation>Gibt an, ob fuer den Versicherten ein aerztlicher Selektivvertrag vorliegt.
Dieses Datenfeld ist besonders schuetzenswert und daher nicht frei auslesbar, sondern nur berechtigten Personen zugaenglich.
Schluesselverzeichnis:
1 = aerztlicher Selektivvertrag liegt vor
0 = aerztlicher Selektivvertrag liegt nicht vor
9 = aerztliches Selektivvertragskennzeichen wird nicht genutzt</xs:documentation>
<xs:element name="Zahnaerztlich" type="VSD:codeDigit">
<xs:documentation>Gibt an, ob fuer den Versicherten ein zahnaerztlicher Selektivvertrag vorliegt.
Dieses Datenfeld ist besonders schuetzenswert und daher nicht frei auslesbar, sondern nur berechtigten Personen zugaenglich.
Schluesselverzeichnis:
1 = zahnaerztlicher Selektivvertrag liegt vor
0 = zahnaerztlicher Selektivvertrag liegt nicht vor
9 = zahnaerztliches Selektivvertragskennzeichen wird nicht genutzt</xs:documentation>
<xs:documentation>Gibt die Paragraphen des SGB V an, in denen Selektivvertraege beschrieben sind.
Die Angaben gelten fuer folgende Selektivvertraege:
1. Stelle: Hausarztzentrierte Versorgung (§73b)
2. Stelle: Besondere ambulante aerztliche Versorgung (§73c)
3. Stelle: Strukturierte Behandlungsprogramme (§137f)
4. Stelle: Integrierte Versorgung (§140a)
Die Stellen 1 und 3 koennen den Wert = 1 (true) nur annehmen, wenn Aerztlich = 1 (true) ist.
Die Stellen 2 und 4 koennen sowohl zur Kennzeichnung aerztlicher als auch zahnaerztlicher Selektivvertraege genutzt werden.
Beispiel: 1000
Es liegt ein Selektivvertrag fuer die Hausarztzentrierte Versorgung nach §73b vor.
In der Testphase koennen die Krankenkassen im geschuetzten Bereich die Paragraphen des SGB V, in denen Selektivvertraege beschrieben sind (§§73b, 73c, 137f, 140a), im Rahmen der offenen Speicherkapazitaet
32
abbilden.</xs:documentation>
<xs:element name="Beginn" type="VSD:ISO8601Date"/>
<xs:element name="Ende" type="VSD:ISO8601Date" minOccurs="0"/>
<xs:element name="ArtDesRuhens" type="VSD:codeDigit">
<xs:documentation>Dieses Feld dient ausschließlich zur Angabe des ruhenden Leistungsanpruchs nach § 16 Abs. 3a und § 16 Abs. 1 bis 3 SGB V.
Mögliche Ausprägungen des ruhenden Leistungsanspruchs sind:
1 = vollständig
2 = eingeschränkt
</xs:documentation>
<xs:attribute name="CDM_VERSION" type="VSD:CDMVersion" use="required"/>
<xs:complexType name="Kostentraeger">
<xs:element name="Kostentraegerkennung">
<xs:documentation>Gibt den Kostentraeger des Versicherten an. Es handelt sich um das bundesweit gueltige Institutionskennzeichen (IK) des jeweiligen Kostentraegers.</xs:documentation>
<xs:element name="Kostentraegerlaendercode">
<xs:documentation>Gibt den Kostentraegerlaendercode vom Kostentraeger des Versicherten an.
Anlage 8 (Staatsangehörigkeit und Länderkennzeichen für Auslandsanschriften) zur DEÜV, V. 2.34 vom 3.09.08.</xs:documentation>
<xs:element name="Name" type="VSD:name">
<xs:documentation>Gibt den Namen der Institution/Organisation an.</xs:documentation>
<xs:complexType name="LandType">
<xs:element name="Wohnsitzlaendercode">
<xs:documentation>Gibt das Land zu der Strassen- und oder Postfachadresse an. Soweit Angaben zur Adresse und zum Postfach gemacht werden, muss der Wohnsitzlaendercode zu beiden Adressdaten vorhanden sein.
Anlage 8 (Staatsangehörigkeit und Länderkennzeichen für Auslandsanschriften) zur DEÜV, V. 2.34 vom 3.09.08</xs:documentation>
<xs:simpleType name="name">
<xs:simpleType name="nameExtension">
<xs:simpleType name="numberWithLeadingZero">
<xs:simpleType name="codedString">
<xs:simpleType name="codeDigits">
<xs:simpleType name="codeDigit">
<xs:simpleType name="booleanInteger">
<xs:simpleType name="boolean">
<xs:simpleType name="ISO8601Date">
<xs:documentation>Format: YYYYMMDD (ISO-8601) </xs:documentation>
<xs:simpleType name="CDMVersion">
<xs:documentation>Version 5.2.X </xs:documentation>
<xs:simpleType name="insurantId">
<xs:documentation>1. Stelle: Alpha-Zeichen (Wertebereich A - Z, ohne Umlaute), 2. bis 9. Stelle: 8-stellige lfd. Zaehlnummer (Eine Ziffernfolge, in der mehr als drei gleiche Ziffern hintereinander auftreten, ist auszuschliessen),
10. Stelle: Pruefziffer</xs:documentation>
<xs:simpleType name="gender">
(Hinweis: Die Abkürzung CDM steht für Corresponding Data Model)
33
2 Screenshots der XSD-Ressourcen, die in der Grafik auf Seite 18 enthalten sind. Beachten Sie das die Screenshots die Files in der
Ansicht zusammengeklappter Tags zeigt, nur der zweite Screenshot zeigt ausschnittweise die entpackte Ansicht:
>
34
35
>
36
37
Glossar, siehe :
http://www.telematik-infrastruktur.de/basis-rollout-telematik-glossar-egk-hba-gesundheitskarte-lonely.php?did=2
Impressum:
Rolf D. Lenkewitz
Systemadministrator
87769 Oberrieden
http://www.meinegklage.de
http://www.it-ler-analysiert-die-egk.de
38

Download Report