Im Gesundheitsbereich ist für IT Software Hersteller und Dienstleister weltweit ein lukrativer Markt vorhanden. Trotz knappen Budgets - wie kann das sein? Nun das liegt zum Großteil an der Gesetzgebung und behördlichen Auflagen. Großangelegte Programme der Regierungen wie HIPAA/HL7 in den USA oder diverse Europäische Verordnungen und Deutsche ("Modernisierungs")-Gesetze haben zu einer komplexen Landschaft geführt. Behörden, Leistungserbringer, Dienste und Clearingstellen müssen aus einem sehr kleinen Angebot von hochpreisigen und altertümlichen Lösungen das richtige Produkt finden.
Dabei kann man weder den Lösungsanbietern böse sein (da die ein riessigen Aufwand treiben müssen um die Regulierungen zu verstehen) wenn sie Ihre Marktposition ausnutzen, noch kann man die Regulation per-se verteufeln. Denn Arzneimittelsicherheit, Rohstoffüberwachung, Pharma-Zulassungsverfahren, Geräteüberwachungen oder auch nur Datenaustausch-Vereinheitlichung sind ja durchaus Bereiche in denen Vorgaben sinnvoll und notwendig sind. Immerhin geht es hier um Menschenleben. Und ganz nebenbei auch um riesige Goldtöpfe die es zwischen den Interessengruppen aufzuteilen gilt. Allen vorweg(?) an die "Leistungsbezieher".
Dabei kann man weder den Lösungsanbietern böse sein (da die ein riessigen Aufwand treiben müssen um die Regulierungen zu verstehen) wenn sie Ihre Marktposition ausnutzen, noch kann man die Regulation per-se verteufeln. Denn Arzneimittelsicherheit, Rohstoffüberwachung, Pharma-Zulassungsverfahren, Geräteüberwachungen oder auch nur Datenaustausch-Vereinheitlichung sind ja durchaus Bereiche in denen Vorgaben sinnvoll und notwendig sind. Immerhin geht es hier um Menschenleben. Und ganz nebenbei auch um riesige Goldtöpfe die es zwischen den Interessengruppen aufzuteilen gilt. Allen vorweg(?) an die "Leistungsbezieher".
Die Spezifikationen in diesem Umfeld sind übrigens wirklich zum Schmunzeln:
Datenaustausch mit Leistungserbringern und Arbeitgebern
Spezifikation der Schnittstellen für die Übermittlung von Nachrichten mittels http
Man Beachte die Seite 7, der Aufbau der HTTP Rückmeldung:
Ja genau, "Erfolgreich beendet oder abgebrochen" ist genau das was man lesen will. Und wieso überhaupt dieses Anschreiben (mit Textbausteinen!) wenn es doch um automatisierten Datenaustausch geht? Wäre ein HTTP Statuscode nicht sinnvoller? Und wieso Zeilenumbrüche, im Rest der Spezifikation steht etwas von HTML Antwort (ach ja, die Mime Header sind natürlich auch nirgends vorgegeben).
Richtlinien für den Datenaustausch mit den gesetzlichen Krankenkassen
Interessant hier die Seite 63 mit einem Ausflug in die Historie (Absatz 4.3 erklärt was US-ASCII ist und Absatz 4.3.1 beschreibt dann, dass dieser Zeichensatz nicht benutzt wird?!). Na immerhin wird der Zeichensatz--Vorrat komplett im Anhang abgedruckt...
Na zum Glück leben in diesem unseren Land nur Menschen mit deutschen Namen.
Über die Unsinnigkeit von Viren Prüfungen von DOS Disketten und CDs, nicht aber von Magnetbändern lasse ich mich jetzt besser garnicht aus....
Ach ja, der Grund warum ich diesen Artikel schrob ist übrigens nicht, dass ich mich aktuell mit der Implementierung beschäftige, sondern vielmehr mußte ich wieder über die enorme Zahl von unterbeschäftigten Security-Experten im HIPAA Bereich den Kopf schütteln. Jede Google Suche ein Treffer :)
Zum Weiterlesen
Healthcare-IT Vertical Report auf CIO.de
Datenaustausch mit Leistungserbringern und Arbeitgebern
Spezifikation der Schnittstellen für die Übermittlung von Nachrichten mittels http
Man Beachte die Seite 7, der Aufbau der HTTP Rückmeldung:
Die Übertragung wurde erfolgreich beendet oder abgebrochen<CR LF>
...
Ja genau, "Erfolgreich beendet oder abgebrochen" ist genau das was man lesen will. Und wieso überhaupt dieses Anschreiben (mit Textbausteinen!) wenn es doch um automatisierten Datenaustausch geht? Wäre ein HTTP Statuscode nicht sinnvoller? Und wieso Zeilenumbrüche, im Rest der Spezifikation steht etwas von HTML Antwort (ach ja, die Mime Header sind natürlich auch nirgends vorgegeben).
Richtlinien für den Datenaustausch mit den gesetzlichen Krankenkassen
Interessant hier die Seite 63 mit einem Ausflug in die Historie (Absatz 4.3 erklärt was US-ASCII ist und Absatz 4.3.1 beschreibt dann, dass dieser Zeichensatz nicht benutzt wird?!). Na immerhin wird der Zeichensatz--Vorrat komplett im Anhang abgedruckt...
Der Bezugscode für den Austausch digitaler Daten ist der Code gemäß DIN 66 303- DRV8
(Deutsche Referenzversion des 8-Bit-Code). Dieser Code enthält die Ziffern, die Groß- und
Kleinbuchstaben, Sonderzeichen sowie nationale Buchstaben, so dass eine korrekte
deutschsprachige Namensschreibung ermöglicht wird.
Na zum Glück leben in diesem unseren Land nur Menschen mit deutschen Namen.
Über die Unsinnigkeit von Viren Prüfungen von DOS Disketten und CDs, nicht aber von Magnetbändern lasse ich mich jetzt besser garnicht aus....
Ach ja, der Grund warum ich diesen Artikel schrob ist übrigens nicht, dass ich mich aktuell mit der Implementierung beschäftige, sondern vielmehr mußte ich wieder über die enorme Zahl von unterbeschäftigten Security-Experten im HIPAA Bereich den Kopf schütteln. Jede Google Suche ein Treffer :)
Zum Weiterlesen
Healthcare-IT Vertical Report auf CIO.de
Trackbacks
Trackback-URL für diesen Eintrag
Keine Trackbacks
Layout by Ricky Wilson | Serendipity Template by Carl Galloway | Login
Impressum
Bernd Eckenfels
Mörscher Str. 8
76185 Karlsruhe
bernd-2012@eckenfels.net
Read More
Suche
Kategorien
Verlinkung
- HIPAA [744]
- HL7 [698]
- Arzneimittelsicherheit [732]
- Pharma-Zulassungsverfahren [780]
- Geräteüberwachungen [771]
- Datenaustausch-Vereinheitlichu
ng [727] - "Leistungsbezieher" [783]
- Spezifikation der
Schnittstellen für die
Übermittlung von Nachrichten
mittels http [273] - Richtlinien für den
Datenaustausch mit den
gesetzlichen Krankenkassen [294] - Healthcare-IT [419]
- dsalksafdedf.com [4]
- www.facebook.com [4]
- www.facebook.com [4]
- Strategic Board Bot (+http [2]
- www.google.ch [2]
- www.junchiseals.com [2]
- www.eckes.org [1]
- www.eckes.org [1]
- www.google.com [1]
- www.google.ch [1]
- www.google.de [1]
- www.google.de [1]
- www.planet.nl [1]
- www.google.ch [1]
- www.google.de [1]
Kommentare
Bernd zu Passwortsicherheit
2012-02-04 17:28
123 zu Passwortsicherheit
2012-02-04 14:43
bl123 zu Passwortsicherheit
2012-02-04 14:25
Edith - die Zauberkünstlerin zu Passwortsicherheit
2012-02-04 13:00
Bernd zu Passwortsicherheit
2012-02-04 10:59
Oliver// zu Passwortsicherheit
2012-02-04 10:34
Christian zu Passwortsicherheit
2012-02-03 14:53
Michael zu Java Stream mit Puffer einlesen
2011-12-13 08:06
2011-08-17 05:22
Blog abonnieren
Blogsphere
Letzten Monat...
Sa, 07.01.2012"Java 7 - Probleme mit neuen JSSE Features"
Di, 03.01.2012"Eckpunktepapier der BNetzA zu Smart Grids und Markets"
So, 01.01.2012"SQL Server JDBC Probleme"
Fr, 30.12.2011"Facebook Events im Google Kalender"
Mo, 19.12.2011"E-Mail versenden von Amazon EC2"
