Hallo Forum,
i
ch bin gerade dabei, mit und in einer Abteilung, die für Ihre Robustheit bekannt ist, und daher immer für derartige Tests herhalten muss, KIM im klinischen Einsatz zu etablieren. Obwohl die wirklich ganz scharf drauf wären, Alternativen zum Fax zu haben, stoße ich mit KIM auf sehr viel Ablehnung, was mir vollkommen plausibel erscheint, angesichts der Begründungen, die sie liefern.
Neben den üblichen Verdächtigen wie die verschiedenen Bundesgesundheitsminister, die gematik undsoweiter sehe ich aber auch eklatante Mängel an den bei uns eingesetzten Komponenten. Man wird mich fragen, ob es keine Alternativen gibt. Ein Wechsel ist zwar unrealistisch, aber ich wüsste dennoch gerne die Antwort, daher dieser Post.

Wir sind ein Haus mit stark 400 Betten, benutzen i.s.h.med und das in omniconnect (x-Tention) integrierte KIM-Modul. Taas kommt von Aquinet.

Zwei der Hauptprobleme beim integrieren von KIM in den klinischen Prozess sind:

Die Dokumenttypen, für die jeweils ein eigenes "customizing" erstellt werden muss, damit sie mit KIM verschickt oder nach dem Empfang im KIS gespeichert werden können. Ist das in anderen KIS auch so? Ich stehe mit diesen Dokumenttypen absolut auf Kriegsfuss (auch in anderen Zusammenhängen). Ich rede nicht von PDF, JPG, Word-Dokument..., sondern von Arztbrief, vorläufiger Arztbrief, OP-Bericht etc....

Die Tatsache, dass der Austausch zwischen i.s.h.med und KIM (geeignetes custoimizing vorausgesetzt) nur möglich ist, wenn die Dokumente im Patientenorganizer sichtbar sind. gibt es dafür eine Begründung? Wir haben Fälle, in denen Papierdokumente direkt in' s Archiv gescannt werden, und anschließend verschickt werden sollten (mit KIM). Das gleicht dann dem Schuss durch die Brust in's Knie. Von Erleichterung keine Spur....

Ich wüsste einfach mal gerne, ob andere KIM-Anwendungen dies einfacher handhaben, oder "ob das so sein muss", und ob diese Dokumenttypen in andere KIS auch existieren oder ob das ein SAP-Relikt ist.

Durchhalten!
(sagt mein Chef)

Zanko

Ich habe bei diesem angezettelten 'Feldversuch', obwohl das KIM-Modul just beim längsten Schulungstermin nicht funktionierte, bereits einige für uns sehr wichtige Dinge mitgenommen, die a priori unabhängig vom System sind, und die ich einfach mal teilen wollte:

1) Eine fast Mantra-artig vorgetragene Forderung (oder auch Wunsch): Nicht ein zusätzliches Verfahren, bitte! Entweder Fax oder KIM. Damit wird ein Schalter-Umlegen gefordert, d.h. ein langsames Einführen abgelehnt. Jenseits irgendwelcher technischer Unzulänglichkeiten ist dies schon deswegen ausgeschlossen, weil nicht alle Kommunikationspartner schon Kimmen können oder wollen. Bereiten Sie sich auf diese Debatte vor!

2) Geringe Akzeptanz wegen umständlicher Handhabung der KIM-Software (bei uns: omniconnect). Dem hatte ich nichts entgegenzusetzen außer dem hoffen auf künftige updates.

3) Das wichtigste für mich: Wir sind beim planen und vorbereiten von völlig falschen Paradigmen ausgegangen, und haben überlegt: Mit welchen (einzelnen) Dokumenttypen, die wir für den KIM-Versand oder -Empfang vorsehen, erzielen wie die größte Arbeitserleichterung (und damit Akzeptanz). Dieser Ansatz hat sich als grundsätzlich falsch erwiesen. Betrachtet werden müssen gesamte Workflows. Beispiel: wir haben aktuell im Programm den KIM-Versand von OP-Berichten, nicht aber von Pathologiebefunden. Unsere Gynäkologie verschickt aber typischerweise an die Zuweiser einen OP-Bericht samt dem pathologischen Befund. Völlig zurecht erklären sie: entweder sie verschicken das ganze Bundle per KIM oder gar nichts. OP-Bericht per KIM und Pathobefund per Fax bewirkt auf beiden Seiten zusätzliche Arbeit, und darüber hinaus mache man sich damit ja lächerlich. Dem hatte ich nichts entgegenzusetzen. Man sollte also eher darauf abzielen, ganze Kommunikationspakete vom Fax wegzubringen, als nach und nach die Dokumenttypen in der Reihenfolge der Häufigkeit für KIM vorzubereiten.

Es bleibt spannend!