100M Gesundheitsakten im Jahre 2015 in USA gehackt

Wenn wir uns in Deutschland über Elektronische Akten unterhalten und in Deutschland Systeme implementieren und einsetzen, die z.B. auch in USA (HL7 Standard) zum Einsatz kommen, sollten sich Patienten sich stets auch die Technik hinterfragen.

Wo sind meine Daten gespeichert?
Wie sind meine Daten vor unbefugten Zugriff geschützt?
Wird für Abbrechungen und Studien anonymisiert oder nur pseudonymisiert?
Welche Gefahren entstehen bei einem Verlust?

Ein paar aktuelle Informationen wie es NICHT laufen sollte.
Gesundheitsakten in USA gehackt

191 Millionen hochsensible Daten (inkl. wer hat welche Partei gewählt)

Diese beiden Datensätze kombiniert können erhebliche Probleme bereiten.

 

Palliativgesetz und Sterbehilfegesetz beschlossen

Seit dem 06.11.2015 haben wir in Deutschland ein neues Palliativgesetz und eine neue Regelung für die Sterbehilfe. Feedback von den Ärzten ist relativ eindeutig: Sollte ein Arzt  sogar nur Medikamente verschreiben, so dass der sterbende Patient selbst das Ableben herbeiführen kann, so macht sich der Arzt strafbar. Schauen wir uns den Entwurf einmal genauer an.

Zunächst das Palliativgesetz

Der Datenschutz hat sich nicht wesentlich verrändert

(…) Daten dürfen nur mit schriftlicher Einwilligung und nach vorheriger schriftlicher Information des Versicherten erfolgen(…)

Dies ist insoweit relevant, dass auch andere Gesetze wie das eHealth oder die derzeitige Diskussion, den Datenschutz zu lockern, um mehr Wirtschaftlichkeit zu ermöglichen, sich dann auch hiermit auseinander setzen müssen. Sollte also auch in Zukunft eine rege elektronische Kommunikation von Nöten sein, so ist doch stets eine schriftliche Einwilligung notwendig. Die Tatsache, dass die elektronischen Unterschriften Pads, wie bei Supermärkten an der Kasse oder  von DHL, nicht rechtssicher sind, da diese Geräte nicht den Druck des Stiftes erkennen, impliziert, dass in Zukunft nicht komplett auf Papier und Stift verzichtet werden kann.

Bzgl. Sterbehilfe steht im Gesetz

 Der Ruf nach Sterbehilfe und/oder assistierter Selbsttötung ist in vielen Fällen Unwissenheit und Angst geschuldet: Unwissenheit in Bezug auf die Möglichkeiten der Palliativmedizin und -pflege und der hospizlichen Unterstützung, Angst vor Einsamkeit, vor Demütigung und insbesondere davor, anderen Menschen zur Last zu fallen. Der Unwissenheit kann mit Informationen begegnet werden, den genannten Ängsten mit einer Sozialpolitik, die sich dem Ziel einer „sorgenden Gemeinschaft“ verpflichtet.

Somit konzentriert sich in der Tat das Palliativgesetz ausschließlich auf die Eingruppierung von Palliativmedizin in die Regelversorgung Zusäztliche Vergütungen für SAPV und Krankenhaus, soll die Versorgung in den nächsten Monaten und Jahren vorantreiben.

Am gleichen Tag wurde jedoch auch noch ein Entwurf für die Sterbehilfe durch den Bundesrat beschlossen.

Dieser Text ist zunächst äußerst verwirrend, da immer wieder davon gesprochen wird, dass das existierende Gesetz, welches eine gewerbsmäßige Sterbehilfe unter Strafe stellt geändert werden muss in eine geschäftsmäßige Sterbehilfe.

Um das ganze zu kürzen: Man nahm sich die Definition geschäftsmäßig aus einem Telekommunikationsgesetz, in dem klar gestellt wird, dass das Wort Geschäftsmäßig auch Nicht-Gewinn-Erbringend bedeutet.  Zudem soll es keine Angebote geben, die eine Normalisierung der Sterbehilfe herbeiführen könnten. Weiterhin bedeutet geschäftsmäßig, dass die Tätigkeit nicht nur einmal durchgeführt wird, sondern regelmäßig.

Klartext: Gäbe es auch nicht gewinnbringende Organisationen, die eine aktive Sterbehilfe durch Medikation oder Apparaturen unterstützen, so würde sich in der Gesellschaft eine gewisse Normalität der aktiven Sterbehilfe etablieren.

Hierzu zwei Zitate aus dem Entwurf:

Auch nicht auf Gewinnerzielung ausgerichtete Angebote können primär durch die Zielsetzung motiviert sein, die eigene „Dienstleistung möglichst häufig und effektiv zu erbringen“ (…)

 

„die Wiederholung gleichartiger Taten zum Gegenstand seiner Beschäftigung macht“

Hingegen wird gesagt:

Somit ist die Suizidbeihilfe, also jede physische oder psychische Hilfeleistung zum eigenständig durchgeführten freiverantwortlichen Suizid, grundsätzlich straffrei. Strafrechtlich erfasst und verboten ist demgegen- über in § 216 StGB die Tötung auf Verlangen.

weiterhin

Selbst eine Einwilligung in die eigene Tötung kann also keine rechtfertigende Kraft für einen zur Tötung bestimmten Dritten entfalten.

und zu guter letzt

Auch bei aussichtsloser Prognose darf Sterbehilfe nicht durch gezieltes Töten, sondern nur entsprechend dem erklärten oder mutmaßlichen Patientenwillen durch die Nichteinleitung oder den Abbruch lebensverlängernder Maßnahmen geleistet werden, um dem Sterben – gegebenenfalls unter wirksamer Schmerzmedikation – seinen natürlichen, der Würde des Menschen gemäßen Verlauf zu lassen

Angehörige gehen straffrei aus, wenn Sie den Wunsch des Erkrankten respektieren und denjenigen unterstützen. Bei einer emotionalen Bindung an den Erkrankten wird nicht von geschäftsmäßiger Sterbehilfe gesprochen, sondern von Humanität.

 

 

 

eHealth Gesetz – was kommt da auf uns zu?

Das eHealth Gesetz…schauen wir es und doch einmal genauer an.

Versicherte, die mindestens drei verordnete Arzneitmittel anwenden, haben ab Ok. 2016 Anspruch auf einen Medikationsplan in Papiperform.

Ein äußerst interessanter Aspekt.  Es ist ja bekannt, dass die Kombination von Medikationen zu sogenannten Kontraindikationen führt und eine Erkrankung verschlimmern können oder neue Erkrankungen hervorrufen. In Zukunft könnten durch einen elektronischen Medikationsplan sowie einem entsprechenden Dienst (Arnzeimitteltherapiesicherheit) diese Probleme obsolet werden.

Die KBV und der Spitzenverband prüfen bis Ende 2016, ob eine reine elektronische Kommunikation zwischen den Ärzten möglich ist.

Interessant und gefährlich zu gleich. Gerade bei medizinischen Daten muss der Datenschutz aber auch die Datenstruktur sicher sein. Ein Beispiel wie man es nicht machen sollte haben wir in der Nähe. England -> Artikel

Technisch und vom Datenschutz interessant ist der Folgende Absatz zur elektronischen Gesundheitskarte:

Soweit es zur Notfallversorgung erforderlich ist, ist der Zugriff auf Daten (…) ohne eine Autorisierung der Versicherten zulässig. Ansonsten muss der Zugriff protokolliert werden und der Versicherte muss sein Einverständnis gegeben haben.

In diesem Szenario müssten die Systeme eine Art „Notfall“ Befehl aussenden, der es mir ermöglicht die Daten auszulesen. Zum anderen müsste so etwas protokolliert werden. Bei der aktuellen eKG ist der Datenspeicher nur ein wenige Bytes gross. Entsprechend wäre ein aufwendiges Protokoll überhaupt nicht möglich. Entweder die Systeme loggen die Zugriffe selbst, doch dann kann ich auch eine Anwendung schreiben, die mir die Daten ausliest per Notfallknopf ohne dass der Patient das wirklich mitbekommt, oder wir kriegen wieder alle neue Karten, oder die Systeme werden dazu verpflichtet einen Aufruf in die Telematik zu machen, um das Log zu speichern – doch dann könnte bei einem Verlust der Datenkontrolle auch wieder jeder sehen, bei welchem Arzt man zuletzt war.

Bund der Krankenkassen, Vereinigung, ..(…) schaffen für die Nutzung der eGK die Telematikinfrastruktur

Hier zu dieser Link 

 

Äußerst interessant, aus technischer Sicht:

Systeme, die zum Erheben, Verarbeiten und Nutzen von personenbezogenen Patientendaten eingesetzt werden, sollen so bald wie möglich offene und standardisierte Schnittstellen zur Archivierung und Übertragung von Patientendaten eine einem Systemwechsel integriert werden.

Ich bin gespannt.

Kommen wir zu etwas Geld

Ab Juli 2016 bis Juni 2018 gibt es für jeden Entlassbrief 1 Euro, sofern dieser elektronisch an einen anderen Arzt übermittelt wurde.

Bestandteil sind Diagnosen, Befunde, Therapiemaßnahmen, Medikation bei Entlassung aus dem Krankenhaus, Entlassungsgrund und empfohlene Rehabilitationsmaßnahmen

Die Annahme von elektronischen Entlassbriefen wird nochmals mit 50 Cent vergütet.

Nimmt man sich die Statistik von GBE-Bund.de zur Hand, so hatten alle Krankenhäuser im Jahr 2013 insgesamt 19,2 Millionen Patienten. Ca. 2000 Krankenhäuser gab es in DE zu diesem Zeitpunkt.  Also knapp 9600-10000 Patienten pro Krankenhaus pro Jahr.

Ansonsten seht weiterhin viel Gesetzestext drin, der wischiwaschi und nicht viel weiteres hergibt.

Bis zum März 2016 möchte man von den Gremien und Verantwortlichen Spezifikationen und Empfehlungen haben, damit die digitale Revolution beginnen kann. Ich bin gespannt.

Zum Entwurf

Buchführungspflicht nach GoBD – Revsionssicherheit, elektronische Archivierung

Jedes Unternehmen wird sich mit den Grundsätzen zur ordentlichen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (kurz. GoBD) auseinander setzen müssen. Gegenüber der landläufigen Meinung existieren dort jedoch keine konkreten Vorgaben bzw. Begrifflichkeiten wie Revisionssicherheit.

Unternehmen sind verpflichtet eine kurzfristige fortlaufende Buchung Ihrer Ein und Ausgaben vorzunehmen sowie die Aufbewahrung von Unterlagen. Papier aber auch elektronische Dokumente, sofern diese für das abwickeln des jeweiligen Geschäftsvorfalls notwendig waren. Elektronische Dokumente gehören ebenso zum Geschäftsvorfall, wenn diese für die Abwicklung notwendig waren (Rechnung, Lieferschein u.s.w.)

Den entsprechenden Entwurf kann man sich beim Bundesfinanzministerium herunterladen.

Kapitel 12 ist zunächst äußerst interessant:

Die Vielzahl (…) der DV-Systeme (…) lassen keine allgemeine gültigen Aussagen der Finanzbehörde zur Konformität (…) zu.

weiter

Zertifikate oder Testate Dritter (…) entfalten (…) gegenüber der Finanzbehörde keine Bindungswirkung.

Viele Produkte sprechen von Revisionssicherheit, wenn diese für die elektronische Archivierung genutzt werden sollen. Doch diese Begrifflichkeit finden sich in keinen der Texte wieder. Vielmehr ist für das Bundesfinanzamt wichtig, dass bei der elektronischen Archivierung  eine Unveränderlichkeit der Dateien existiert. Soll bedeuten. Kann ich sicherstellen, dass meine elektronischen Daten über die Jahre nicht verrändert wurden, so ist das System völlig ausreichend. Die großen Storage Hersteller bieten für so eine Lösung WORM Speicher an. Eine DVD/BlueRay ist so ein Speicher. In der Theorie reicht aber auch aus, dass ich z.B. eine Möglichkeit habe eine Datei zu hashen. Dieser Hashwert sollte sich neben den Dateinformationen auch aus dem aktuellen Zeitpunkt des hashens bestehen. Weiterhin ein Logfile und fertig ist die Lösung zum Archivieren von elektronischen Dateien.

Weiterhin wichtig ist die Glaubhaftigkeit des Steuerpflichtigen bzw. bei komplexen Verfahren eine Verfahrensdokumentation, um eine genaue Beschreibung des Verfahrens zu haben.

Nun noch ein paar wenige Zitate als Auszug:

Eine Buchung (…) darf nicht in einer Weise verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist.

 

Veränderungen (….) müssen protokolliert werden.  (…) Für elektronische Dokumente gilt dies sinngemäß.

 

Der Steuerpflichtige hat sein DV-System gegen Verlust (…) zu sichern.

 

Das zum Einsatz kommende DV-Verfahren muss die Gewähr dafür bieten, dass Informationen (…) nicht (…) überschrieben, gelöscht, geändert oder verfälscht werden

 

Die Unveränderbarkeit der Daten (…) kann (…) hardwaremäßig (z.B. unveränderbare und fälschungssichere Datenträger) als auch softwaremäßig (z.B. Sicherung, Sperren, Festschreibung, Löschmerker,  automatische Protokollierung, Historisierung, Versionierungen) als auch organtisatorisch (z.B. mittels Zugriffsberechtiungskonzepten) gewährleistet werden. Die Ablage von Daten (…) in einem Dateisystem erfüllt die Anforderungen (…) nicht.

 

Eine maschinelle Auswertbarkeit ist (…) bei (…) Daten (…) geben, die

  • mathematische-technische Auswertungen ermöglichen,
  • eine volltextsuche ermgölichen,
  • auch ohne mathematische-technische Auswertungen eine Prüfung im weitesten Sinne ermöglichen.

Wie man sieht ist im Prinzip alles halb so wild. Idealerweise hat man neben seinem Buchungssystem (Datev und Co.) eine Software und/oder Hardware in dem ich meine elektronischen Rechnungen speichere. Diese Software ermöglicht durch ein Zugriffsberechtigungssystem und Hashwert + Logfile, die Unveränderbarkeit bzw. Nachvollziehbarkeit und schon bin ich auf der sicheren Seite.

Selfhosted Service – Port freischalten

Der Selfhosted Service ist fertig. Damit wir den Service aber auch ansprechen können und auch so gut wie möglich unter realen Bedingungen testen, habe ich mir bei Microsoft Azure eine VM erstellt.

Als nächstes müssen wir nicht nur bei Azure den Port freischalten auf dem der Service lauscht, sondern auch unter Windows.

Hierfür öffnen wir eine Admin Powershell und geben z.B. folgenden Befehl für Port 7000 ein.

netsh httpa>add urlacl url=http://*:7000/ user=BUILTIN\Users listen=yes

Alle User die in der Windows Gruppe Users sich befinden dürfen nun den Selfhosted Service starten. Dadurch wird der Dienst nicht als Admin gestartet und man hat ein wenig mehr Sicherheit

 

MongoDB referentielle Integrität

Bei No SQL Datenbanken existiert so etwas wie referentielle Integrität nicht, da keine Tabellen (relationales Schema) vorliegt.

Folgende Klasse sei gegeben

public class Auftrag{
public Kunde MeinKunde {get;set;}
}

Das Problem hierbei ist, dass jeder Auftrag einen eindeutiges Objekt der Klasse Customer zugeordnet bekommt. So ist man es auch von der üblichen OO-Programmierung gewohnt. Speichert man nun einen Auftrag in der Datenbank ab, wird jedem Auftrag eine Kopie des MyCustomers mitgespeichert.

Anders als bei relationalen Datenbanken, können wir somit zunächst nicht die Eigenschaften des MyCustomers (z.B. Straßennamen, Rechnungsadresse)  ändern und diese Änderung an alle Aufträge weiterreichen. Der übliche Workaround wäre ein Query auf alle Aufträge, vergleichen aller Customer Objekte oder der Klasse Auftrag ein Identifier MyCustomerID hinzuzufügen. Weiter oben im Layer die Logik einbauen, dass mittels MyCustomerID das Objekt Customer aus der DB geholt wird.

Die Prozessschritte wären:

1. Erstelle ein Customer oder wähle einen vorhandenen aus
2. Füge die ID einer neuen Aufgabe hinzu
3. Speicher die Aufgabe
4. Öffne die Aufgabe
5. Lese die CustomerID aus
6. Führe ein Query aus, um den Customer zu holen.

public class Auftrag{
  public String meinKundeId;
}

Würde gehen, ist jedoch Rotze. Kein guter Programmierer würde solch eine Lib jemanden geben wollen. 

In .NET haben wir jedoch die Möglichkeit auf Propertys zurückzugreifen, wodurch wir folgendes machen können:

public class Auftrag {      
  String meinKundeId{ get; set; }
        public Kunde MyKunde
        {
            get
            {
               if (meinKundeId==null) return null;
               return DBService.GetObject<Customer>(meinKundeId);
            }
            set
            {
                this.meinKundeId= value.Id;
            }
        }
}

Hier ist nun ein Property, welches das Field myCustomerId kapselt. Das besondere ist nun, dass man überall im Code nun einfach

var c = Auftrag.MeinKunde;

aufrufen kann und das Customer Objekt zurückbekomme. Die wesentliche Funktion hier ist die DBService Funktion. Es handelt sich hierbei um ein DB Proxy, welcher aus der Datenbank ein Objekt zurückliefert. Als Query Parameter wird der Primäry Key, die ID, mitgeliefert.

Somit haben wir einen schönen Workaround für unsere referentielle Update-Integrität.

Die DBService Klasse ist eine Art Wrapper für sämtliche Datenbanken, die man nutzen möchte. Am einfachsten ist es ein Interface zu definieren, welches implementiert werden muss, wenn man die Klassen Auftrag, Customer etc nutzen möchte.

29.05 Update – Referentielle Integrität

Eine andere Variante ist es  eine Service Klasse zu implementieren, die sämtliche Modelle entgegen nimmt und Rekursiv auf Complexe Propertys untersucht. Anschließend werden die übrig gebliebenden einfachen Datentypen in der Datenbank gespeichert. Da Mongo automatisch eine ID für das gespeicherte Objekte zurückliefert, können wir dieses wiederum in einer Liste übernehmen und somit auf oberster Ebene ein SaveMongoObject erstellen, in dem nur zwei weitere Propertys liegen: ClassType und PropertyList<ID>.

Auch Abrufen ist dadurch möglich, indem die Objekte dank Reflectoin neu aufgebaut werden.

Vorteil dieser Variante ist, dass keinerlei Abhängigkeit der Modelklassen  zu der MongoDB haben müssen – entgegen der obrigen Version.

Nachteil: Die Datenbank ist absofort nur noch ein reiner Speicherort, in dem Daten nicht mehr wirklich menschenlesbar sind.

Abschließend

Zum Schluß kann man sagen: Entweder man entscheidet sich für eine OO Sicht und nutzt eine NoSQL DB oder man lässt es bleiben und greift lieber direkt auf eine SQL DB zurück. Ein ORM Mapper kann auch ganz nützlich sein. Man sollte somit vorher genau überlegen, was man benötigt.

Lightswitch HTML Client – the method or operation is not implemented

Manchmal ist es zum verrückt werden. Dieser Fehler tauchte immer auf, wenn ich versucht habe ein neues Lightswitch HTML Client Projekt zu erstellen.

Lösung: Umstellen der Einstellung:

Options –> Source Control -> Git Source Control Provider

 Options –> Source Control -> Visual Studio Team Foundation Server

Git Source Control – Keine Tortoise GIT Icons mehr nach Update in Visual Studio 2012

Wer wie ich das Problem hatte, dass nach einem Update von Tortoise GIT dieses nicht mehr in Visual Studio in Kombination mit GIT Source Control Provider nutzen konnte…hier die Lösung:

In VS12 –> Tools –> Source Control –Git Source Control Provider OptionsTortoise Git

Und hier muss der Path aktualisiert werden. TortoiseProc.exe heisst inzwischen TortoiseGitProc.exe.

Das wars auch schon.

 

Finger weg von toList() Methode – Zu langsam

Problem:

In einem Webprojekt, in der die objektorientierte Datenbank db4o zum Einsatz kommt, passierte es nach einigen Wochen auf, dass die Seite immer langsamer wurde. VIEEEELL langsamer.

Natürlich kam zunächst der Gedanke: Javascript ist schuld.

Mittels Mini-Profiler  habe ich eine Analyse gemacht und gesehen, dass die Datenbankabfrage selbst Ursache ist. Komisch! Und tatsächlich

beispielcode:
System.Diagnostics.Stopwatch watch = new System.Diagnostics.Stopwatch();
watch.Start();
db.query<meinobjectclass>().where(x=> x.value > 3).toList<meinobjectclass>();
watch.Stop();

 zeigt mir 450 oder bis zu 700 ms an. Bei 40.000 – 50.000 Objekten. Definitv zuviel. Die Suche im Internet ergab, dass ich nicht der einzige bin, der Performance Probleme hat mit der List. Lange rede kurze Fakten: Einfach toList weglassen und mit IEnumerable arbeiten.

Und weil ich schon am testen war mit db4o..hier mal meine Ergebnisse:

List Größe:50645. Dauer des Linqquery:8 ms
List Größe:50645. Dauer des NativeQuery:60 ms
List Größe:50645. Dauer des Query mit Konvertierung zu List :2883 ms

. Es ist natürlich nicht die Datenbankabfrage selbst die daher langsam ist, sondern die Konvertierung, in der das .NET Framework einiges an Speicheroperationen durchführt.

WebClient mit Clientzertifikat

Problem: Nutzen der WebClient Klasse, um z.B. einen RestFul Aufruf zu machen, der mit Zertifikaten gesichert ist.

Lösung:

class MyWebClient : WebClient
{
        protected override WebRequest GetWebRequest(Uri address)
        {
            HttpWebRequest request = (HttpWebRequest)base.GetWebRequest(address);
           request.ClientCertificates.Add(
X509Certificate2.CreateFromCertFile(@"meinClientZertifikat.cer"));

            return request;
        }
}

Und nun

var client = new MyWebClient();
var data = client.DownloadData(meineUrl);