Sumex II IRP: Intelligente Rechnungsprüfung im Gesundheitswesen mit Hilfe eines BRMS

Transkript

1 Sumex II IRP: Intelligente Rechnungsprüfung im Gesundheitswesen mit Hilfe eines BRMS SI-SE 2008 Jonas Kurth, ELCA

2 Kurzporträt ELCA Werbung ;-) ELCA ist eines der grössten unabhängigen Softwareentwicklungsund Systemintegrationsunternehmen der Schweiz. Wir entwickeln, integrieren, betreiben und warten IT Lösungen basierend auf kundenindividuellen Anforderungen oder als Standardlösungen. Gegründet ! Mitarbeiter Niederlassungen Umsatz > 450 Mitarbeiter Lausanne (Hauptsitz), Zürich, Genf, Bern, London, Madrid, Paris, Ho Chi Minh City (Vietnam) CHF 57 Millionen, seit 20 Jahren stets positive Ergebnisse Qualitätsstandards ISO 9001 seit 1993 CMMI Level 3 seit 2007 Auszeichnungen 1 ELCA JKU

3 Sumex wie? 2 ELCA JKU

4 Die Sumex II Familie Sumex II ist ein Set von Applikationen für die Leistungskontrolle im Schweizer Gesundheitswesen (Krankenkassen, Unfallversicherungen, etc.) Im Detail werden durch diese Familie die folgenden 3 Bereiche abgedeckt: Automatisierte Abwicklung von elektronischen Rechnungen Sumex II: Belegverarbeitung Batchverarbeitung grosser Datenmengen (in der Regel in der Nacht) Sumex II Online Verarbeitung für SABE (am Tag) Verwaltung von Tarif- und Referenzdaten Sumex II TMS: Stammdaten Verwaltung Tarifdaten Referenzdaten Business Regeln und Workflow-Steuerung Sumex II IRP: Business spezifische Regeln Vom Fach direkt verwaltete Regeln Intelligenter Flow Control Sumex II TMS Sumex II IRP ELCA JKU

5 Sumex II: Ein Kernsystem im CH-Gesundheitsmarkt Projektstart 1999, seit ca in Produktion Gesamtanzahl verarbeiteter Rechnungen: > 45 Millionen Zirka 1.8 Millionen Rechnungen pro Monat Tendenz stark steigend Hohe Performanz: bis zu Rechnungen pro Tag (tönt nach wenig, ist aber aufgrund der z.t. sehr umfangreichen Prüfungen sehr viel) Zirka Sumex II Clients ausgebreitet Der Marktanteil von Sumex II liegt aktuell bei zirka 60% Sumex II wird dank seiner grossen Flexibilität in unterschiedlichen Konstellationen und Umgebungen eingesetzt und kann einfach integriert werden (Produkt + Framework) Entwicklung durch Sumex II Benutzergruppe mit Kostenteilung 4 ELCA JKU

6 Auch für Sie im Einsatz? Die folgenden Versicherungen (u.a.) benützen im Moment Sumex II: 5 ELCA JKU

7 Sumex II Haupttechnologien Überblick Sumex II 1.5 IDE Sumex II TMS 1.5 IDE + RCP Sumex II IRP 1.5 IDE + RCP 6 ELCA JKU

8 Was macht Sumex II? Ziel ist eine möglichst hohe Automatisierung... Komplettieren Kontrollieren Freigeben Auszahlen Eingang Format Bei den Auslenkungen, fällt die grosse Arbeit an! 7 ELCA JKU

9 Regeln gibt es schon lange Regeltypen Es ist nicht so, dass bis jetzt keine Regeln verwendet wurden! Bereits jetzt sind in Sumex II und Sumex II TMS Zehntausende von Regeln definiert (z.b. Tarmed-Tarifregeln). Diese sind jedoch in Referenz-Datenbanken gespeichert oder gar fest ausprogrammiert (z.t. durch die IT konfigurierbar) Was ist im Kontext von Sumex II konkret mit Regeln gemeint? Tarifregeln (z.b. in Tarmed) Allgemeine Rechnungsprüfungen (z.b. Beträge, Doppel, etc.) Transkodierungen (Mapping Position Leistungsart / Produkt) Verteilregeln (z.b. Verteilung der Rechnungen zu Teams)... Grosse Abhängigkeit zu Technik bzw. IT Business Know-how muss auch in der IT vorhanden sein Business Regeln unterstehen IT Release Zyklen 8 ELCA JKU

10 Wir möchten unabhängiger von der IT sein... Anforderungen Unsere Kunden (Fachabteilung) sagen: Wir möchten nicht jedes Mal bei einer Änderung der Informatik einen Auftrag geben und etwas entwickeln lassen. Wir erhoffen uns davon eine grössere Flexibilität und eine gewisse Unabhängigkeit zur Informatik. ALT: Business definiert Regeln, IT setzt um NEU: Business definiert und verwaltet Regeln selbständig 9 ELCA JKU

11 Wir möchten mehr Flexibilität Anforderungen Unsere Kunden (Fachabteilung) sagen: Wir möchten gerne unsere eigenen Regeln kreieren, nach denen Rechnungen kontrolliert werden. Diese Regeln möchten wir ad-hoc verändern und testen. Wir möchten mit unseren Regeln Simulationen fahren, um deren Auswirkungen auf das Tagesgeschäft ermitteln zu können. Wie steht es eigentlich mit diesen Business Rule Systemen? BRMS versprechen die obigen Anforderungen erfüllen zu können Mit BRMS kann eine relativ einfache Externalisierung und ein separater Unterhalt der Business-Logik erreicht werden Mit BRMS kann das Applikations-Verhalten (theoretisch) verändert werden, ohne die Applikation neu zu kompilieren. 10 ELCA JKU

12 Wir kennen... Ergonomie Und das ist der Standard, wie ihn unsere Kunden aus Outlook kennen und gewohnt sind: Aktionen Ausnahmen Bedingungen 11 ELCA JKU

13 Was macht nun Sumex II IRP? Mit IRP können einfach und schnell neue Prüfregeln hinzugefügt werden Sumex II IRP Komplettieren Kontrollieren Freigeben Auszahlen Eingang Format Sumex II IRP Mit IRP kann die Quote der Auslenkungen gesteuert werden 12 ELCA JKU

14 Sumex II IRP Konzept + Architektur Sumex II IRP umfasst grundsätzlich 4 Komponenten: 4. Rule Simulation 3. Integration Scenario (Sumex II) 2. Rule Execution Environment 1. Rule Editor Eingesetzte (Haupt-)Technologien: Java 1.5 Eclipse RCP für Rule Editor JBoss Rules für Rule Execution Basis Spring 2.0 incl. Spring MVC (Rule Execution + Simulation) 13 ELCA JKU

15 Fachliche Szenarien (1) Flow Control Szenario Flow Control: Steuerung und Verteilung der Arbeitsbelastung der Sachbearbeiter (SABE) Zuweisung von Rechnungen zu Teams, Agenturen, MA Kontrolle der auszusteuernden Belege (Rechnungen) Sumex II setzt Codes auf Belegen, welche zu Auslenkungen führen würden IRP übersteuert diese Codes unter bestimmten Bedingungen, sodass die Auslenkungen reduziert werden können Auslenkungen Vor IRP Nach IRP Aktivierung von IRP Regeln Zeit 14 ELCA JKU

16 Typische Regelbeispiele Flow Control Konkrete Regeln: Wenn Betrag der Rechnung kleiner als 10 CHF, ignoriere allfällige Fehlercodes auf der Rechnung (d.h. keine Auslenkung zu einem SABE) Wenn PLZ des Leistungserbringers = 8000, dann verschiebe Rechnung zu Team Z Kombinierte Regel: Wenn Position XYZ verrechnet, dann verschiebe diese Rechnung zu Team V und setze Status der Rechnung zu VIS Wenn Status der Rechnung = VIS und Betrag der Rechnung für Team V kleiner als 50 CHF, ignoriere allfällige Fehlercodes auf der Rechnung. Arbeitssteuerung Arbeitsverteilung Regel- Abhängigkeiten (RETE-Einsatz) 15 ELCA JKU

17 Fachliche Szenarien (2) LERB Benchmarking Szenario Leistungserbringer Benchmarking: Statistiken und Bewertungen von einzelnen Leistungserbringern und Gruppen von Leistungserbringern Case Management: Einbezug verschiedener Faktoren wie Leistungserbringer, Arbeitgeber, Patient, etc. Erste Überprüfungen auf Stufe Leistungserbringer Aktuelle Rechnungen werden mit Referenzfällen verglichen Leistungserbringer werden mit ihren Peer-Groups verglichen In Abhängigkeit dazu werden Aktionen ausgelöst Fallkosten (Durchschnitt) LE X Peer Group Differenz zu Peer- Group grösser als Schwellwert Zeit 16 ELCA JKU

18 Regelbearbeitung Grafischer Regel Editor Grafisches Tool für die Bewirtschaftung der Business Regeln Kunde empfand kommerziell erhältliche BRMS zu komplex bzw. zu unhandlich und wünschte ein eigenes Tool (auf Basis OSS) Entwickelt auf der Basis der Eclipse RCP 17 ELCA JKU

19 Verwendung von DSL Generische Regelsprache Der IRP Rule Editor basiert auf DSL (Domain Specific Language), welche als XML geladen werden können. Diese DSL treibt das GUI: 18 ELCA JKU

20 Feedback und Erfahrungen (1) Gewählter Ansatz Pragmatisch und einfach integrierbar in bestehende Sumex II Umgebungen Erste Szenarien behandeln einfache Business Regeln, was den Einsatz vereinfacht Integrierte Regelsimulation erlaubt es den Fachpersonen, selbständig Tests zu fahren und damit die Verantwortung zu übernehmen. Rule Editor Lösungsansatz Sehr positives Feedback (einfach und klar) Potential gross und Aufwand klein für weitere Erweiterungen Generischer technischer Aufbau und flexibles Regelsprachen-Konzept Könnte ohne programmatische Anpassungen z.b. auch für die Kreditabwicklung bei einer Bank verwendet werden 19 ELCA JKU

21 Feedback und Erfahrungen (2) Kritische Punkte Viele kommerzielle BRMS-Editoren sind sehr IDE-lastig Wie viel verstehen hier nicht Technik-versierte (Fach-)Personen? Für unsere Kunden waren diese zu komplex Verwaltung hierarchischer Objekte (bei Sumex II z.b. Rechnungen mit ihren Positionen) Wie werden die Daten geladen? Wie werden die Daten adressiert? Braucht ein (Fach-) Benutzer dazu Programmier- oder DB-Kenntnisse? Inferencing, klassisches Expertensystem, dynamische Änderung von Fakten? Wird diese Dynamik überhaupt noch von Fachpersonen verstanden? Wie kann eine so gefällte Entscheidung einfach und übersichtlich dargestellt werden? Code Injection: Programmcode in Regeln? Editor darf dies nicht zulassen, da ansonsten grosses Sicherheitsloch Separierung durch virtuelle Maschinen (z.b. separate JVM bei Java) Autorisierungprüfungen beim Deployment 20 ELCA JKU

22 Feedback und Erfahrungen (3) Allgemein Rule Lifecycle Es muss der ganze Lifecycle (Rule elaboration, rule mining, reviews, change mangement, revisioning, feedback, rule deletion, etc.) betrachtet werden, nicht nur die Regelerstellung oder die Ausführung Die Erwartungen sind oft (zu) hoch. Eine genaue Bedürfnisanalyse ist notwendig: Welche Regeln profitieren tatsächlich vom Einsatz eines BRMS? In vielen Fällen macht es wenig Sinn, ein BRMS bzw. eine BRE einzusetzen Konkretes Beispiel aus unserer Erfahrung: Tarmed Ein PoC (Proof of Concept) sollte Aufschluss geben über funktionale und nicht-funktionale Anforderungen (wie z.b. Performanz) Es gibt immer einen Trade-off zwischen Flexibilität und Performanz «Je mehr das Business selbst adressieren will, desto mehr geht es in Richtung klassische Programmierung (imperativ) anstelle von Formulierung von Wissen als Regeln (deklarativ / deskriptiv)» 21 ELCA JKU

23 Besten Dank für Ihre Aufmerksamkeit Für weitere Informationen zu Sumex II IRP und zu anderen IT-Lösungen von ELCA kontaktieren Sie bitte: Jonas Kurth Senior Manager Steinstrasse Zürich +41 (0) Lausanne I Zürich I Bern I Genf I London I Paris I Ho Chi Minh City