Grouper für Microsoft Access

  • Hallo Forum,

    ich erstelle gerade eine Datenbank für Auswertung und Dokumentation der MDK-Begehungen und Kassenanfragen.

    Meine Frage:
    Gibt es eine Möglichkeit einen Grouper in Access einzubinden, bzw. über Makros anzusteuern?

    Gruß

    AA

  • Hallo AA,
    ganz einfach - man muß nur ein bisschen programmieren.

    Access-DB öffnen, Extras>Makros>Visualbasic-Editor

    Dort mit Extras>Verweise die Groupersoftware einbinden (normalerweise sollte in der Liste der Grouper zu finden sein, bei uns z.B. DRGScout -ansonsten mit durchsuchen die EXE des Groupers auswählen).

    Dann z.B.
    Sub test()
    Dim grp As New DRGscout.Grouper, Diagnosestring As String, DRG As String

    With grp
    .AddDiagnose (Diagnosestring)
    .Analyze
    DRG = .DRG
    End With

    End Sub

    Ich vermute mal, dass alle Grouperhersteller eine entsprechende ActiveX-Schnittstelle in ihrer Software haben, man muß dann eben bei der eigenen Grouperfirma freundlich nach den OLE-Objekten, Eigenschaften und Methode der Komponente nachfragen, um die Diagnosen, Aufenthaltsdaten usw. dem Grouper übergeben und die Ergebnisse abfragen zu können.

    Viel Erfolg
    P.Dietz

  • Hallo AA,

    mit ID Diacos geht das ganz ähnlich (Texteinrückung leider nicht möglich):
    [hr][courier][f2]

    Option Explicit
    Const Baserate as Single = \"2700\"

    Sub GroupIt() \'Noch besser, eine Funktion mit den relevanten Eingabeparametern mit dem OPTIONAL-Parameter

    Dim Alter as Integer, Aufnahme as String, Entlassung as String, Entlassungsart as Integer
    Dim HD as String, NDs as String, Procs as String

    \'Eingaben; am besten natürlich mittels Formular einsammeln
    Alter = 55
    Aufnahme = \"01.01.2005\"
    Entlassung = \"10.01.2005\"
    Entlassungsart = 1 \'normale Entlassung
    HD = \"I1000\" \'Alternative: \"I10.00\"
    NDs = \"E11.60;N08.3;N18.83\"
    Procs = \"8930;1631;1440a\" \'Alternative: \"8-930;1-631;1-440.a\"

    Dim KrGrouper As IdGrouper.JKrgrouper
    Set KrGrouper = New JKrgrouper
    \'Mit \"New\" geht\'s noch eine Zeile kürzer

    With KrGrouper
    .newCase
    .Baserate = Baserate \'Baserate in Euro
    .ageY = Alter \'Alter in Jahren
    .adt = Aufnahme \'Aufnahmedatum
    .sdt = Entlassung \'Entlassungsdatum
    .sep = Entlassungsart \'Entlassungsart, nicht gesetzt = -1
    .pdx = HD \'Hauptdiagnose
    .sdx = NDs \'Nebendiagnosen
    .srg = Procs \'Prozeduren
    .doGroup
    .proceed (.DRG)
    .drginfo (.DRG)

    \'Ausgabe ins Direktfenster; am besten natürlich in Formularfelder einfügen

    Debug.Print .DRG & \" (\" & .catalogue_idpartition & \")\" \'DRG
    Debug.Print .drg_rubric \'DRG Klartext
    Debug.Print .mdc \'MDC
    Debug.Print .mdc_rubric \'MDC Klartext
    Debug.Print .pccl \'PCCL
    Debug.Print .proceed_idcw \'CW Katalog
    Debug.Print .proceed_idabschl_days_g \'Abschl. UGV
    Debug.Print .proceed_idabschl_days_v \'Abschl. Verlg.
    Debug.Print .proceed_idabschl_cw_eff \'Abschl. CW
    Debug.Print .proceed_idcw_eff \'CWeff
    Debug.Print .proceed_idzuschl_days \'Zuschl. OGV
    Debug.Print .proceed_idzuschl_cw_eff \'Zuschl. CW
    Debug.Print .catalogue_idabschl_beg \'UGV
    Debug.Print .catalogue_idalos \'MVD
    Debug.Print .catalogue_idzuschl_beg \'OGV
    Debug.Print .proceed_result \'Erlös
    Debug.Print .department \'CW-Abt

    End With
    End Sub
    [/f2][/courier][hr]

    Auch von mir viel Erfolg! (Wird ein hartes Stück Arbeit, aber lohnt...)

    Thomas Rauner
    Allgemeinarzt
    med. Controlling

  • Hallo,

    ich merke schon, dass dieses Thema wohl mehr Leute berührt als ich gedacht habe.
    Ich habe mich mit KODIP kurzgeschlossen und hoffe von denen eine adäquate Unterstützung zu bekommen.
    Euere Antworten haben mich aber auch schon ein großes Stück weitergebracht.

    Gruß

    AA

  • Schönen guten Tag allerseits!

    Vielen Dank AA, für die Frage und vielen Dank insbesondere an Herrn Rauner für den Tipp. Auf dieser Basis habe ich einen kleines und noch unvollständiges Tool zu gruppierung von § 21 Daten erstellt:

    [hr]
    VBA-Code:

    Function SQLListe(SQL As String, _
    Optional SepR As String = \";\", Optional SepF As String = \";\", _
    Optional NoNullFields As Boolean = True) As String
    \'
    \' Diese Funktion dient dazu, aus mehreren Datensatzfeldern einen String zu erstellen
    \' (für Nebendiagnosen und OPS)
    \' Vielen Dank für den Tipp an das MS-Office Forum und http://www.DBWIKI.de
    \'
    \' Die Felder, die mit dem SQL-String gewonnen werden,
    \' werden feldweise mit SepF, datensatzweise mit SepR getrennt
    \' Wenn NoNullFields gesetzt ist, werden leere Felder unterdrückt
    \'
    Dim RS As DAO.Recordset, I As Long, Res As String, Tmp As String

    \' Microsoft DAO muss über <Extras><Verweise> eingebunden sein

    On Error Resume Next
    Set DB = CurrentDb()
    Set RS = DB.OpenRecordset(SQL, dbOpenSnapshot)
    If Err <> 0 Then
    Res = \"#Fehler\"
    Else
    On Error GoTo 0
    Res = \"\"
    Do While Not RS.EOF
    Tmp = \"\"
    For I = 0 To RS.Fields.Count - 1
    If Not (NoNullFields And IsNull(RS(I))) Then Tmp = Tmp & SepF & RS(I)
    Next
    If Tmp <> \"\" Then Res = Res & SepR & Mid(Tmp, Len(SepF) + 1)
    RS.MoveNext
    Loop
    RS.Close
    If Res <> \"\" Then Res = Mid(Res, Len(SepR) + 1)
    End If
    SQLListe = Res
    End Function

    [hr]
    \' Der eigentliche Grouper

    Function GroupIt(ADatum, EDatum, AlterJ, AlterT, EArt, HD, ND, OPS, Beatm, Optional Modell) As String

    \' Diacos-Grouper über <Extras><Verweise><Durchsuchen...> und auswählen der IDGrouper.dll im Diacos-Verzeichnis einbinden


    Dim KrGrouper As IdGrouper.JKrgrouper
    Set KrGrouper = New JKrgrouper
    \'Mit \"New\" geht\'s noch eine Zeile kürzer

    \' Auswahl des Groupermodells Vereinfacht über den Parameter \"Modell\" in der Form
    \' \"<ICD/OPS-Jahr> - <DRG-Jahr>\" (noch rudimentär)
    \' ohne Angabe des Modells erfolgt das Groupen nach den Aufnahmejahr

    With KrGrouper

    If Not IsMissing(Modell) Then
    Select Case Modell
    Case \"2004-2004\"
    .grouper_model = \"G21-ICD10_GM2004-OPS301_2004\"
    Case \"2004-2005\"
    .grouper_model = \"G31-ICD10_GM2004-OPS301_2004\"
    End Select
    End If

    \' Übernahme der Patientendaten

    .newCase
    .AgeY = AlterJ \'Alter in Jahren
    If AlterJ = 0 then .ageD = AlterT \'Alter in Tagen (nur wenn AlterJ = 0)
    .adt = ADatum \'Aufnahmedatum
    .sdt = EDatum \'Entlassungsdatum
    .sep = EArt \'Entlassungsart, (erste beiden Stellen des Entlassungsgrundes: 01 = Normal, 06 =Verlegung usw.)
    .pdx = HD \'Hauptdiagnose
    .sdx = ND \'Nebendiagnosen
    .srg = OPS \'Prozeduren
    .hmv = Beatm \'Beatmungszeit

    \' Grouping
    .doGroup

    \' Ermittlung der DRG-Parameter (hier nicht erforderlich)
    .Proceed (.drg)
    .DrgInfo (.drg)

    \'Ausgabe der DRG als Funktionsergebenis

    GroupIt = .drg
    End With
    End Function

    [hr]

    In Access müssen die Tabellen Fall, ICD und OPS aus dem §21 Datensatz als Tabellen importiert werden.

    Dann sind noch folgende Abfragen zu erstellen:

    [hr]
    Abfrage ICDString zur Umwandlung der Nebendiagnosen in einen String:

    SELECT ICD.IK, ICD.[KH-internes-Kennzeichen], sqlliste(\"select [ICD-Kode], [Sekund{r-Kode] from ICD where [Diagnoseart] = \'ND\' and [KH-internes-Kennzeichen] = \'\" & [KH-internes-Kennzeichen] & \"\'\") AS ICDString
    FROM ICD
    GROUP BY ICD.IK, ICD.[KH-internes-Kennzeichen]
    WITH OWNERACCESS OPTION;

    [hr]
    Abfrage OPSString zur Umwandlung der Prozeduren in einen String:

    SELECT OPS.IK, OPS.[KH-internes-Kennzeichen], sqlliste(\"select [OPS-Kode] from OPS where [KH-internes-Kennzeichen] = \'\" & [KH-internes-Kennzeichen] & \"\'\") AS OPSString
    FROM OPS
    GROUP BY OPS.IK, OPS.[KH-internes-Kennzeichen]

    [hr]
    Abfrage Grouperinput zur Zusammenstellung der Eingabeparameter:

    SELECT FALL.IK, FALL.[KH-internes-Kennzeichen], DateValue(Format([Aufnahmedatum],\"0000-00-00 00\\:00\")) AS ADatum, DateValue(Format([Entlassungsdatum],\"0000-00-00 00\\:00\")) AS EDatum, FALL.[Alter-in-Jahren-am-Aufnahmetag] AS AlterJ, FALL.[Alter-in-Tagen-am-Aufnahmetag] AS AlterT, [Entlassungsgrund]\\10 AS EArt, IIf([ICD-Kode] Is Null,\"\",[ICD-Kode]) AS HD, IIf([ICDString] Is Null,\"\",[ICDString]) AS ND, IIf([OPSString] Is Null,\"\",[OPSString]) AS OPS, IIf([Beatmungsstunden] Is Null,0,Val([Beatmungsstunden])) AS Beatm
    FROM ((FALL LEFT JOIN OPSString ON (FALL.[KH-internes-Kennzeichen]=OPSString.[KH-internes-Kennzeichen]) AND (FALL.IK=OPSString.IK)) LEFT JOIN ICD ON (FALL.[KH-internes-Kennzeichen]=ICD.[KH-internes-Kennzeichen]) AND (FALL.IK=ICD.IK)) LEFT JOIN ICDString ON (FALL.[KH-internes-Kennzeichen]=ICDString.[KH-internes-Kennzeichen]) AND (FALL.IK=ICDString.IK)
    WHERE (((ICD.Diagnoseart)=\"HD\"))

    [hr]
    und schließlich die Abfrage DRG als Ergebnis, hier mit den DRGs 2004-2004 und 2005-2005:


    SELECT Grouperinput.IK, Grouperinput.[KH-internes-Kennzeichen], Groupit([ADatum],[EDatum],[AlterJ],[AlterT],[EART],[HD],[ND],[OPS],[Beatm]) AS DRG, Groupit([ADatum],[EDatum],[AlterJ],[AlterT],[EART],[HD],[ND],[OPS],[Beatm],\"2004-2005\") AS [DRG 2005]
    FROM Grouperinput
    [hr]
    [hr]

    In diesem Beispiel wird nur die DRG ermittelt, die anderen Daten müssten dann selbst berechnet werden. Daher ist auch die Eingabe der Abteilungsart beispielsweise nicht erforderlich.

    Dies ist nur ein Beispiel für diejenigen, die hier weiter experementieren wollen. Es ist weder ausgereift, noch wird irgendeine Gewährleistung übernommen.

    Ich wünsche noch einen schönen Tag,

  • Hallo AA,

    ich hatte mir vor einiger Zeit selbst überlegt soetwas auch für unser Haus zu schreiben. Leider bin ich noch nicht dazu gekommen den Punkt anzugehen.

    Wirst du die Datenbank veröffentlichen? Besteht evtl. die Möglichkeit mir eine Kopie zukommen zu lassen, damit ich diese auf unsere Bedürfnisse anpassen kann. Das wäre wirklich Klasse. Ich würde dir auch die Schnittstelle zum Grouper implementiere. Wir arbeiten hier mit dem Kermanog Grouper.

    Schöne Grüße

    Tim

  • Zitat

    ich erstelle gerade eine Datenbank für Auswertung und Dokumentation der MDK-Begehungen und Kassenanfragen.
    Meine Frage:
    Gibt es eine Möglichkeit einen Grouper in Access einzubinden, bzw. über Makros anzusteuern?

    Hallo Forum,

    saublöde Frage am Rande: Warum muss sich Arzt sowas eigentlich selber programmieren? Ich meine, ich bin ja auch gerne Hobby-Programmierer, und es sind auch für die Arbeit schon etliche Programme entstanden, ohne die ich nicht glücklich controllen könnte :d_zwinker:; trotzdem schiebt doch jedes Krankenhaus Monat für Monat einen Batzen EURO über den Tresen, ohne das das typische KIS des Jahres 2005 den Workflow von der Entlassungsanzeige über KK-Anfrage, MDK-Gutachten bis hin zum Sozialgerichtsprozess ordentlich als Workflow abgebildet hat. Man stelle sich vor, die Krankenkassen-Mitarbeiter müssten Ihre Werkzeuge auch selber programmieren. :g_muhahaha:

    Dadurch gehen den Krankenhäusern weitere EURO jeden Tag :d_pfeid: <flöten>.

    Muss das so sein? Bei meinem KIS-Hersteller habe ich zuletzt ebenfalls eine entsprechende Entwicklung eines MDK-Arbeitsplatzes angeregt. Mal sehen, was draus wird.
    P.S. an Herrn Schaffert: Kriegen Sie für Ihre nicht eben trivialen EDV-Übungen einen von diesen EURO mehr von Ihrem Arbeitgeber :i_respekt: ? Nur so \'ne Frage ...

    Thomas Rauner
    Allgemeinarzt
    med. Controlling

  • Hallo Herr Rauner und die Anderen,

    warum das Arzt selber macht? Weil\'s dann so aussieht, wie\'s die \"Kunden\" wollen!

    Ich will mal ein paar Beispiele nennen:
    1. Groupen
    Unser SMS-KIS medico//s - es heißt, es sei recht verbreitet - bietet mir keine Möglichkeit, mal ein paar Diagnosen zu erfassen oder mal ein paar wegzulassen, ohne immer gleich abrechnungsrelevante Sätze zu erstellen. Also braucht man einen \"Testgrouper\". Dazu holt man sich das, was schon vorhanden ist an Diagnosen und Daten aus der Datenbank und füttert einen Grouper. Dann programmiert man noch ein Knöpfchen, um z.B.mit Kodip ein paar Diagnosen und/oder Prozeduren zu ergänzen oder auch in MDK-Manier zu deaktivieren. Sehr überzeugend gegenüber Kollegen, denen man ohne viel Federlesens Ihre \"Dokumentation\" auch mal \"um die Ohren hausen\" muß - oder die Motivation der Beatmungsstunden-Eingabe zu erhöhen.
    2. Korrekte Darstellung des AKTUELLEN Entgeltes
    Z.B. rechnet medico//s - solange der Pat. stationär ist - immer das Entgelt für den FOLGE-Tag aus - in meinen Augen völliger Nonsens, aber das SMS-Productmanagement hält das für ein tolles Feature. Befindet sich der Pat. unterhalb der unteren bzw. bei Verlegung der mittleren VWD, habe ich also solange der Pat noch da ist, ein anderes Ergebnis (ein Tag mehr) als wenn ich den Pat. tatsächlich 5 Minuten später entlassen habe (richtig Verweildauer).
    3. SAPS/TISS
    DAS konnte man mit einiger Erfahrung wirklich problemlos selber machen. Und kostet mit Sicherheit weniger als ein Kaufprogramm.
    4. \"Können Sie mir sagen, wieviele Pat. mit H-TEP eine Luxation derselben erlitten haben?\"
    Sagt uns unser KIS mit ORACLE nicht freiwillig. Auch dafür tut man sich leichter mit Programmierkenntnissen. Für Spezial-Fragestellungen, die die Chefärzte immer wieder mal haben - und die immer wieder gleichlautend wiederkehren - baut man halt am leichtesten ein \"Quick\'n\'Dirty\"-Programm um die Datenbank-Abfrage, finde ich.
    5. DRG-Vergleiche
    Wessen KIS kann schon die Zahl der kalkulierten DRGs mit der aktuellen jederzeit für Chefs und Oberärzte vergleichbar darstellen? Unseres nicht - und wenn, nur mit PDM und nur für eingeweihte User mit speziellen Rechten (\"Statistik-Modul\").

    usw.usw.

    Alles Gründe, warum im MC auch die EDV nicht zu kurz kommen darf. Ich will nicht verhehlen, dass es damit auch Probleme gibt/geben kann. Ist der ärztliche Programmierer halt nicht da, gibt\'s ein Problem, wenn ein Problem auftritt. Denn leider ist in den meisten Fällen die eigene Doku nicht so umfänglich, dass der nicht-ärztliche Berufsprogrammierer das Problem schnell lösen könnte.
    Auch hat man ein Problem, wenn man Daten speichern will - ins KIS schreiben ist nicht zu empfehlen! Man muß also die eine oder andere - auch redundante Tabelle - nebenher führen. Dazu braucht man in der EDV noch einen verständigen DB-Admin.
    Und zuletzt hat der KIS-Hersteller eine Daumenschraube namens Update. Jedesmal spannend, ob mal wieder Tabellen geändert wurden, aus denen man seine Informationen bezieht. Dann heißt es nachsitzen.

    Natürlich kann man als \"Hilfsprogrammierer\", der in seiner 50 % Arbeitszeit im MC noch DRGs kontrollieren muß, nicht das Rad neu erfinden. Wenn man aber sieht, dass das halbe Klinikum mosert, wenn mal was Selbstgestricktes nicht geht, dann ist das auch was wert ;)

    Nun - es soll ja auch schon Bestrebungen geben, dass Krankenhäuser Ihre Ergänzungen der Programme austauschen...siehe auch diese Diskussion.

    Viele Grüße
    P.Dietz

  • Hallo Herr Dietz,

    hach, Sie reden mir so aus der Seele;

    genau die Diskussion haben wir im Krankenhaus auch schon öfter geführt, v.a. vor dem Hintergrund, wieviel Zeit man mit solchen Programmierarbeiten nebenher \"totschlägt\". Aber jetzt weiß ich zumindest, dass ich da nicht so ganz alleine stehe auf weiter Flur :grouper:, auch wenn man im eigenen Krankenhaus meist der Einzelkämpfer ist, der dem Vorstand und dem EDV-Leiter ein wenig suspekt ist :d_zwinker: mit seinen ständigen undurchschaubaren Aktivitäten ...

    Trotzdem, nachdem ich meine schwierigeren Programmierjobs schon - unter Protest meiner besten Ehefrau von allen - mit nach Hause schleppe, weil ich sonst für die tägliche Auseinandersetzung mit unseren Freunden von der Kasse und dem MDK keine Zeit mehr hätte :biggrin:, bin ich dennoch der Ansicht, dass Ihre und meine Anforderungen an ein KIS nicht so weltfremd sind, als dass es ein KIS-Hersteller in BPflV-adäquater Gutsherren-Manier (Ich: Guru, Du: Anwender, leise!) weiterhin vermeiden kann und darf, auf die täglichen und massiv entgelt-relevanten Anforderungen v.a. der Ärzte im Krankenhaus zu reagieren.

    Wie schon beschrieben, ich habe zusammen mit unserem KIS-Hersteller vereinbart, zu den mir wichtigsten Themen (DRG-Arbeitsplatz für die Kollegen, MDK-Arbeitsplatz für mich) konkrete Vorschläge zu unterbreiten (ich mache demnächst eine offiziell genehmigte Dienstreise in die Firmenzentrale), und ich habe das Gefühl, dass der Hersteller (iSoft Bochum) durchaus interessiert ist. Natürlich will ich meine eigenen mühsam erarbeiteten Kenntnisse nicht verkümmern lassen, grade um im Notfall auf die \"kleine Frage vom Kollegen Chefarzt zwischendurch\" auch mal ein Ass aus dem Ärmel ziehen zu können. Nachdem ich die jährliche Angst vor dem Diacos-Update bzw. den Katalog-Umstellungen und die regelmäßige Unbehaglichkeit bei Eintrudeln neuer KIS-Updates sehr gut nachvollziehen kann, kann ich mir auf Dauer nicht vorstellen, dass ich als Einzelkämpfer auf Dauer den Überblick behalten kann. Sind Sie da optimistisch?

    Ganz zu schweigen von der Abhängigkeit derartiger Lösungen von meiner Person; wer soll\'s denn machen, wenn ich mal nicht da bin? Klar, für mich ist das schon schmeichelhaft, \"wenn man gebraucht wird\" und unentbehrlich ist. Betriebswirtschaflich sind solche Emotionen aber blanker Unsinn, weil meine Tätigkeit ja erheblich über das Wohl und Wehe von hunderten von Arbeitsplätzen mit entscheidet.

    Man könnte es als EDV-versierter Arzt aber auch den Könnern aus dem \"Speckgürtel des Gesundheitswesens\" nachmachen und sich als EDV-Berater selbstständig machen, um den früheren Arbeitgeber als unabhängiger Unternehmer kräftig abzusahnen :teufel: ?

    Es grüßt Sie ein sehr nachdenklicher

    Thomas Rauner
    Allgemeinarzt
    med. Controlling