Fefes Blog

Fragen? Antworten! Siehe auch: Alternativlos

Fri Nov 24 2006

• [l] Wie ihr vielleicht gesehen habt, hat der CCC eine Kosten-Nutzen-Analyse zur Gesundheitskarte befreit. Ich habe das Dokument mal grob gesichtet, und dabei sind mir folgende Punkte aufgefallen:
  1. [Seite 68] Die Kosten für die Ausgabe der Karten wird zwar ermittelt, fließt aber nicht in die Kosten-Nutzen-Analyse ein, weil das "nicht KNA-relevant im Sinne des Workshop 1" sei.
  2. [Seite 86] Ein zweites Rechenzentrum für Ausfallsicherheit ist nicht vorgesehen. "Da solche Disaster-Recovery-Architekturen die Gesamtkosten eines solchen Dienstes oft verdoppeln und die verpflichtenden Anwendungen auch offline allein auf Basis der eGK funktionsfähig sind, wird von einer Berücksichtigung von Disaster Recovery für die KNA abgesehen." Aufmerksame Beobachter werden sicher gemerkt haben, daß das weniger Redundanz als bei den Österreichern ist, und schon denen ist ihr System mehrfach um die Ohren geflogen
  3. [Seite 87] Für die Application Server gibt es N+1 Redundanz, d.h. ein Server mehr als man braucht. Wenn zwei ausfallen, hat man dann halt ein Problem.
  4. Die Zahlen kommen auf gruselige Art und Weise zusammen; so sind für die meisten Dienste nicht nur die Software noch nicht fertig, es gibt noch nicht einmal eine Spec, was der Dienst genau tun soll. Und so zieht sich der Gutachter die Zahlen dann eben aus dem Ar^Hllerwertesten, z.B. daß Threads jeweils 200 KB RAM brauchen, und zwar offenbar unabhängig von der Anwendung, um die es gerade geht. Laut Fußnote ist das eine "Expertenschätzung Booz Allen Hamilton". Dann schätzt die Studie auf ähnlicher Grundlage den RAM-Bedarf der Rechner, indem die Anfragen (pro Sekunde?) genommen werden, und man das mit den 200 KB multipliziert. Glücklicherweise ist dann da ein Rechenfehler drin, so daß sie doppelt so viel RAM verplanen wie sie brauchen, ansonsten wäre das echt problematisch geworden.
  5. Ein weiteres Beispiel dafür, daß die Zahlen keinerlei Realitätsbezug haben, ergibt sich beim Storage-Sizing des eVerordnungs-Dienstes. Hier nimmt die Studie einfach an, daß die Datensätze nach einem Jahr gelöscht werden.
  6. Überhaupt scheint da jemand nicht rechnen zu können. Bei den Lastberechnungen (Seite 89) liefert eine Schätzung der gematik (die durchführende Firma) für Peak-Last bei einer Epidemie die Zahlen. Die Zahlen gehen von 2160 Verordnungen pro Stunde pro Apotheke aus, bei 22.000 Apotheken, und dazu 80 Verordnungen pro Praxis, bei 103.000 Praxen. Die Zahlen scheinen mir eine grobe Schätzung zu sein, wie viel Verordnungen die jeweilige Infrastruktur maximal ausstoßen kann, zumindest bei den Apotheken, denn 2160 Verordnungen pro Stunde bei den Apotheken, das sind unter zwei Sekunden pro Verordnung. Das ist auch ungefähr die Zeit, die alleine der Chipkartenleser brauchen wird. Booz Allen Hamilton zählt das zusammen und kommt auf 28.000 Verordnungen pro Sekunde (bei meinem Taschenrechner sind es 15.500), und kommt dann mit folgendem Kracher: "Aus gutachterlicher Sicht ist dieser Wert substantiell zu hoch.".

     Dann nimmt das Gutachten diesen Wert, um die Anzahl der benötigten Server zu berechnen, indem sie TPC-Werte nehmen und die Verordnungen durch die TPC-Werte teilen. Sie haben als typische TPC-Werte 100-200 Transaktionen pro Sekunde bestimmt, diese Werte kommen wohl von IBM und Sun, also geben sie als Ergebnis an, daß man dann ja 70-140 Server bräuchte. Mhh. Also wenn ich ihre 28.000 Verordnungen nehme, komme ich auf 140-280 Server, und wenn ich meine 15.500 Verordnungen nehme, komme ich auf 78-155 Server.

     Wieso erwähne ich das mit den TPC-Werten? Das sind Hardware-Benchmarks, die Hersteller benutzen (wie ehemals die MIPS-Angaben bei CPUs), um ihre Hardware gut aussehen zu lassen. Die TPC-Werte haben mit real erreichbaren Transaktionen so gut wie nichts zu tun. Da hat der Hersteller unter Laborbedingungen tiefergelegt mit Spezial-Builds, besonders viel Cache, handgetunetem OS usw. versucht, maximale Marketing-Zahlen zu erreichen. Das für ein reales Server-Sizing zu nehmen ist hanebüchen.

  7. Besonders skurril ist eine Frage bei dem Fragebogen im Anhang:

     Ist geplant, über die Pflicht- und freiwilligen Anwendungen hinaus noch weitere Anwendung über die eGK zu realisieren (z.B. Bonusprogramme, usw.)?"

  8. Es fällt auf, daß alle Schätzwerte (wie viele Anrufe sie in ihrem Callcenter erwarten, …) einen margin of error haben — nicht aber die Entwicklungskosten für ihre Spezialanwendungen. Da nimmt die Studie in einem Fall z.B. einfach mal 25 Personenjahre Aufwand an, ohne daß auch nur eine Spec vorliegt für diesen Dienst, und so viel sind es dann halt für die Kalkulation. Das Risiko, daß die Entwicklung nicht fertig wird, ist überhaupt nicht erfaßt. Wieso erwähnen die diese ganzen Dienste, wo es gar keine Spec für gibt? Weil in dem Nutzenmodell die Nutzen hauptsächlich durch diese optionalen, freiwilligen Dienste reinkommen (z.B. die Notfalldaten, wo dann auf der Karte gespeichert ist, ob man gegen Tetanus geimpft ist, und gegen welche Medikamente man allergisch oder resistent ist). Also mußten sie diese Dienste berücksichtigen, sonst wäre das von vorneherein ein Totalreinfall gewesen. Das Risiko, daß sie die Hardware für einen Dienst gekauft und hingestellt haben, aber die Software noch nicht fertig ist, und sie dann für die Wartung zahlen, ist auch nicht erwähnt. Wieso haue ich darauf so herum? Weil der neue CEO von gematik der Ex-CEO von der fiscus GmbH ist, dem bei seinem anderen Großprojekt (neue Software für die Finanzämter) genau das passiert ist.
  9. In dem Papier ist von einem MPLS-Backbone die Rede. Da stellt sich ja mir die Frage, ob die das als VPN betrachten, und die Sachen über die Leitung nicht verschlüsseln. Für Verschlüsselung der Daten auf der Leitung habe ich keinerlei Hinweis gefunden, und wenn man bei der Telekom ein VPN kauft, kriegt man gerne mal ein MPLS-Konstrukt verkauft, denn MPLS sorgt ja dafür, daß das nur über Telekom-Leitungen geroutet wird, die sind ja per Definition sicher, also braucht man da nichts zu verschlüsseln. Das mag ja für leichtgläubige Chefs von New Economy Klitschen zutreffen, aber für unsere Gesundheitsdaten brauchen wir schon richtige Absicherung.
  10. An einer Stelle haben sie keine Peak-Zahlen zur Hand, also schätzen sie die, indem sie die durchschnittliche Auslastung mal vier nehmen. Das fand ich besonders putzig, weil der Durchschnitt ja nicht der Tagesdurchschnitt ist, sondern auch die Nachtphase beinhaltet.
  Kurz gesagt: das Papier liest sich wie ein einziges Desaster. Sie haben da mit teilweise deutlich unseriösen Methoden an den Zahlen geschraubt, und selbst mit derartigen Methoden kommen sie nur gerade so auf einen Break Even. Und ihr habt ja gesehen, wie sie die Kosten hier kleinzurechnen versucht haben, und trotzdem ist das schon das dreifache dessen, was sie dem Gesundheitsministerium initial versprochen hatten. Wenn dieses Papier das Projekt nicht kippt, dann weiß ich auch nicht.

  Update: Eine Sache ist noch auffällig: bei mehreren Punkten ignorieren sie Kosten mit dem Hinweis, daß das ja bei den Kosten für die Karten schon drin sei — diese Kosten werden aber anscheinend den Bürgern aufgedrückt, und zählen deshalb nicht als Projektkosten. Noch was: der Krypto-Punkt bezieht sich auf das MPLS. Da ist VPN-Hardware mit IPsec im Einsatz, allerdings nur von dem Arzt zum Backbone, und der läuft per MPLS und hat ~50 Endpunkte, daher denke ich nicht, daß das bloß das LAN im Rechenzentrum sein soll.