Rework prevention tool

698
-1

Published on

Presentación dominio de salud de aplicación orientada a BI.

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
698
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Rework prevention tool

  1. 1. DIANA BENAVIDES<br />JORGE GUÍO<br />Aplicaciones en contextos de granescala: <br />Dominio de salud<br />Rework Prevention Tool<br />
  2. 2. Rework Prevention Tool<br />Data Mining to Predict and Prevent Errors in Health<br />InsuranceClaimsProcessing<br />MohitKumar, RayidGhani, Zhu-SongMei<br />AccentureTechnologyLabs<br />Chicago, IL, USA<br />mohit.x.kumar, rayid.ghani, zhu-song.mei@accenture.com<br />Presentedon: ACM SIGKDD Conference 2010, Washington.<br />http://www.kdd.org/kdd/2010/<br />http://videolectures.net/kdd2010_kumar_dmppeh/<br />http://www.kdd.org/<br />
  3. 3. Rework Prevention Tool<br />CONTEXTO<br />“Mejorar la calidad del servicio, CONTROLANDO LOS COSTOS”<br />Situación: $186 billones de sobre-costos en salud en EU relacionados con altos costos administrativos.<br /><ul><li>Un paciente va a un proveedor de servicios (IPS) para obtener la atención necesaria.
  4. 4. El proveedor de servicios envía una solicitud de pago a la aseguradora en salud (EPS).
  5. 5. La aseguradora en salud procesa la solicitud, teniendo en cuenta un conjunto de variables calcula el pago, y realiza el pago al proveedor.</li></ul>Problema:<br /><ul><li>Rework: Errores en el pago de las solicitudes de pago causan un re-procesamiento de la solicitud. Un re-procesamiento que es una gran porción de los costos administrativos.
  6. 6. 5.000 solicitudes de pago al día, para 3’500.000 clientes. Se procesan 200.
  7. 7. Estos errores causan una pérdida de ingresos de hasta 1 billón cada año – 33% de la mano de obra administrativa se usa en este re-procesamiento.</li></li></ul><li>Rework Prevention Tool<br />DESCRIPCIÓN<br />¿Cómo se soluciona actualmente en las compañías?<br /><ul><li>Auditorías aleatorias: no tiene sentido, la mayoría de las solicitudes son correctas, por lo que es difícil detectar re-work (95 – 98%).
  8. 8. Hipótesis de expertos: hipótesis y reglas son construidos y ejecutados mediante SQL – mucho esfuerzo manual y de expertos. Además son específicos a los planes de salud, por lo que no son re-utilizables. Precisión entre 5-10%.</li></ul>¿Qué se ha hecho en la comunidad de investigación?<br /><ul><li>Overpaymentidentificacion-Enkata: ayuda a identificar causas raíz de solicitudes pasadas “re-work”, no predice.</li></ul>¿Qué se propone?<br /><ul><li>ReworkPreventionTool: Sistema que usa técnicas de Machine Learning para predecir las solicitudes de pago que necesitarán “re-work” (genera explicaciones, acepta feed-back). Reducir costos asociados a la salud</li></li></ul><li>Rework Prevention Tool<br />DESCRIPCIÓN<br />
  9. 9. Rework Prevention Tool<br />DESCRIPCIÓN: Requerimientos de la aplicación<br /><ul><li>Predicción antes del pago: Actualmente el análisis es post-pago, por lo que se incurre en costos para corregir el pago. Áreas de recuperación de cartera.
  10. 10. Generalización: Fácilmente implementable en las aseguradoras en salud: modelo de datos universal, que cubre gran cantidad de reglas de re-work.
  11. 11. Exactitud: Reportar solicitudes de pago sospechosas exitosamente, y mejor a medida que pasa el tiempo: se optimizan las predicciones para las de mayor confianza.
  12. 12. Explicaciones: Habilidad para sustentar el por qué de la clasificación de la solicitud es determinada como sospechosa: UI.
  13. 13. Adaptabilidad: A cambios en legislaciones, contratos, normas: feed-back desde la UI.</li></ul>** A través de clasificación binaria mediante SVM: confidence score **<br />
  14. 14. Rework Prevention Tool<br />ARQUITECTURA DE SOLUCIÓN: Componentes<br /><ul><li>Data Collection: DW con solicitudes de los últimos dos años. Solicitud etiquetada como “correct” o “re-work” tiene que ser capturado desde otros sistemas: Quality Control Audit, Provider Dispute System, FinancialRecoveryProcess.
  15. 15. FeatureConstruction: Hay cuatro tipos de información en cada solicitud: información del paciente, información del proveedor, encabezado de la solicitud, detalle de la solicitud (por cada procedimiento). Creación de nuevos atributos importantes.
  16. 16. ModelLearning and Selection: SVM – SVMperf: 110.000 atributos, después selección de atributos en base a frecuencia. Eficiencia en el entrenamiento del modelo.</li></li></ul><li>Rework Prevention Tool<br />ARQUITECTURA DE SOLUCIÓN: Componentes<br /><ul><li>Scoring: Ejecutar el modelo y clasificar los datos. Una vez hecho, guardar los resultados para ser presentados en la UI.
  17. 17. ExplanationGeneration: Influencia de atributos: peso del atributo según SVM * valor. Se muestra en la UI esta influencia.
  18. 18. Userfeed-back:
  19. 19. Feed-back de la solicitud: Binario, por categoría o mediante texto.
  20. 20. Featurefeed-back: Resaltar o desmarcar atributos mostrados en UI.
  21. 21. User interface
  22. 22. Listado de solicitudes sospechosas, junto con su porcentaje de confianza; atributos resaltados. Esto permite, a la vez: mostrar una interfaz agradable al usuario y obtener feed-back de los auditores.</li></li></ul><li>Rework Prevention Tool<br />Userinterface & userfeed.back<br />data<br />1<br />1<br />2<br />3<br />4<br />4<br />5<br />6<br />DW<br />ExplanationGeneration<br />data<br />classified data<br />Featureconstruction<br />Scoring<br />FinancialRecoveryProcess<br />labeled data + features<br />SVM<br />labels<br />(re-work, correct)<br />ModelLearning and Selection<br />Quality Control Audit<br />Provider Dispute System<br />
  23. 23. Rework Prevention Tool<br />TECNOLOGÍA<br /><ul><li>DW
  24. 24. RelationalDatabases
  25. 25. User Interfaces
  26. 26. Técnicas de Machine Learning: SVM (paquete SVMperf).</li></li></ul><li>Rework Prevention Tool<br />EXPERIMENTO<br /><ul><li>3.5 millones de solicitudes (14 millones de líneas). 121.000 clasificadas, 40% re-work. 33.000 atributos en el dataset.
  27. 27. Métrica: en base a precisión para los top 10: Aseguramiento de exactitud del modelo, puesto que los datos con que se analiza están sesgados hacia re-work(en la vida real es del 2-5%).
  28. 28. Pruebas con reducción de atributos.
  29. 29. Prueba de utilidad de datos más recientes vs. datos históricos (usando series de tiempo).
  30. 30. Pruebas con Active Learning.
  31. 31. Conclusión: experimentalmente una precisión del 92%.</li></li></ul><li>Rework Prevention Tool<br />OPORTUNIDADES A EXPERIMENTAR:<br /><ul><li>Clasificación multi-clase.
  32. 32. Ranking.
  33. 33. Multi-InstanceLearning.
  34. 34. GenericClaimsRework Data-Model.
  35. 35. ClaimsWorkflowIntegration.
  36. 36. ExecutiveDashboard.
  37. 37. Extensión a otros dominios de aseguradoras: reducir necesidad (y costos) de correcciones.
  38. 38. Integración con múltiples canales para enviar alertas a auditores y/o ejecutivos (e-mail, celular…).</li>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×