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 für spezifische URI dieses Eintrags
Keine Trackbacks
Layout by Ricky Wilson | Serendipity Template by Carl Galloway | Login
Impressum
Bernd Eckenfels
Mörscher Str. 8
76185 Karlsruhe
bernd-08(a)eckenfels.net
Read More
Suche
Verlinkung
- Geräteüberwachungen[486]
- HIPAA[437]
- HL7[394]
- Arzneimittelsicherheit[432]
- Pharma-Zulassungsverfahren[443]
- Healthcare-IT[234]
- Datenaustausch-Vereinheitlichu
ng[444] - Richtlinien für den
Datenaustausch mit den
gesetzlichen Krankenkassen[156] - "Leistungsbezieher"[400]
- Spezifikation der
Schnittstellen für die
Übermittlung von Nachrichten
mittels http[151]
Umfrage
Inhouse Coding?
Archive
Archive
Kommentare
Bernd Eckenfels zu DSL und der gefürchtete Parser
2008-08-12 16:59
Hmm Fowler lobt die einfachen DSLs
und sagt man soll dafür einen Parse
r bauen.
Wenn man das aber jetz
t nicht m [...]
2008-08-12 16:59
Bernd Eckenfels zu Arbeitsplatz Schönheit bei der AxelSpringer AG
2008-08-12 10:35
Leider keine Antworten, aber immerh
in hab ich grade nen Artikel gefund
en der oberflächlich beschreibt, wi
e sich Ma [...]
2008-08-12 10:35
Markus Kohler zu DSL und der gefürchtete Parser
2008-08-12 09:04
Hallo Bernd,
IMHO drückt sich Fow
ler davor eine DSL Workbench zu ben
utzen weil das der schwache Punkt v
on "exter [...]
2008-08-12 09:04
Bernd Eckenfels zu Null returns in Java
2008-08-12 03:23
More discussion:
http://andyp-tw
.blogspot.com/2008/08/returning-nul
l-considered-dishonest.html
2008-08-12 03:23
Bernd Eckenfels zu Terminkonflikt
2008-07-21 20:44
Hallo Beate,
ich war leider nich
t dort. Und mich ärgert es auch, da
ss so ein Verein es nicht auf die R
eihe beko [...]
2008-07-21 20:44
Beate zu Terminkonflikt
2008-07-18 21:17
Warst du bei der Vereinsgründung? W
ie wars? Ich finde aber auch nirgen
ds was drüber. Und angeschrieben ha
tte ich a [...]
2008-07-18 21:17
wolfgang bernsdorf zu Arbeitsplatz Schönheit bei der AxelSpringer AG
2008-07-15 19:00
Umstellung auf apple pc. So schöne
pc`s
kann es nicht geben, um gerne
bei Springer zu arbeiten (Spandau)
.
2008-07-15 19:00
Bernd Eckenfels zu Review: Team Beam
2008-07-01 04:35
Es gibt ein kleines Java Programm m
it dem man auf seinen Amazon S3 Acc
ount hochladen kann. Das tool kann
auch time [...]
2008-07-01 04:35
Christian Geisert zu Nostalgie in Sachen DatenFernÜbertragung
2008-06-12 14:47
grummel Registrierung grummel l
ahme Website grummel Download sch
lecht implementiert (falscher Datei
name, kei [...]
2008-06-12 14:47
Bernd Eckenfels zu Kündigungswellen trotz Rekordumsätze
2008-05-30 00:44
Fixed :) Danke Jennifer. Ich hatte
das Archiv gesehen aber da waren ir
gendwie nicht alle Artikel zu sehen
?
2008-05-30 00:44
Blog abonnieren
Blogsphere
Letzten Monat...
Mi, 16.07.2008Software Übersetzungen
Mi, 16.07.2008Terminkonflikt
Di, 15.07.2008Visual Virtualization
Do, 10.07.2008Google Lively
Mi, 09.07.2008Optimierungen beim Java Threading
Mi, 16.07.2008Terminkonflikt
Di, 15.07.2008Visual Virtualization
Do, 10.07.2008Google Lively
Mi, 09.07.2008Optimierungen beim Java Threading
Top Referers
www.google.de (26)
www.google.at (3)
209.85.135.104 (2)
extrabot.com (2)
www.google.ch (2)
search.live.com (1)
www.eckes.org (1)
www.google.hr (1)
www.keywordspy.com (1)
www.michaelreichart.de (1)
www.google.at (3)
209.85.135.104 (2)
extrabot.com (2)
www.google.ch (2)
search.live.com (1)
www.eckes.org (1)
www.google.hr (1)
www.keywordspy.com (1)
www.michaelreichart.de (1)
