Plantilla de Datos: Procesamiento de Siniestros
Tu plantilla de datos para la gestión de siniestros.
- Atributos recomendados para recopilar
- Actividades clave a monitorizar
- Guía de Extracción para Guidewire ClaimCenter
Atributos de Procesamiento de Siniestros
| Nombre | Descripción | ||
|---|---|---|---|
Hora del Evento EventTime | La fecha y hora precisas en que ocurrió la actividad. | ||
Descripción Este timestamp marca el momento exacto en que una activity fue registrada en el system. Es fundamental para todo análisis de procesos basado en tiempo. El orden cronológico de EventTime para un único Claim ID permite la reconstrucción del process flow. La diferencia de tiempo entre events consecutivos se utiliza para calcular cycle times, waiting times y processing times, que son críticos para el performance analysis, bottleneck identification y SLA monitoring. Por qué es importante Este timestamp es esencial para ordenar events, calcular cycle times y durations, e identificar retrasos en el proceso. Dónde obtener Se encuentra junto a los datos de eventos o actividades en las tablas de historial o auditoría de Guidewire ClaimCenter, a menudo como un campo 'CreateTime' o 'UpdateTime'. Ejemplos 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
ID de Siniestro ClaimID | El identificador único para cada siniestro de seguro, que funciona como el identificador principal del caso. | ||
Descripción El ID de Siniestro es la piedra angular del análisis de procesos de siniestros, identificando de manera única cada caso desde su presentación hasta su cierre. Vincula todas las actividades, documentos, pagos y comunicaciones asociados, asegurando una visión completa y coherente del ciclo de vida de un siniestro. En Process Mining, cada evento en el dataset está vinculado a un ID de Siniestro, lo que permite la reconstrucción del flujo de proceso de principio a fin. Esto es esencial para analizar los tiempos de ciclo, identificar variantes de proceso y rastrear el recorrido de un siniestro a través de diferentes departamentos y ajustadores. Por qué es importante Es la clave fundamental que vincula todos los eventos relacionados, permitiendo rastrear y analizar el recorrido completo de un único siniestro. Dónde obtener Esta es una primary key en Guidewire ClaimCenter, que se encuentra típicamente como Claim.ClaimNumber o un field similar en la entidad Claim principal. Ejemplos 000-123-45678000-987-65432001-456-11223 | |||
Nombre de la Actividad ActivityName | El nombre de la actividad de negocio o evento que ocurrió en un punto específico del ciclo de vida del siniestro. | ||
Descripción Este atributo describe un paso o hito específico en el proceso de gestión de siniestros, como 'Siniestro Creado', 'Investigación Iniciada' o 'Pago Emitido'. La secuencia de estas actividades para un ID de Siniestro determinado conforma el flujo del proceso. Analizar la secuencia, frecuencia y duración entre actividades es el núcleo del Process Mining. Permite el descubrimiento de modelos de proceso, la identificación de cuellos de botella, la detección de ciclos de retrabajo y el análisis de desviaciones del proceso. Por qué es importante Define los pasos del proceso, permitiendo la visualización de mapas de procesos y el análisis del flujo del proceso y los cuellos de botella. Dónde obtener Esto se suele derivar de tablas de event o audit logs en ClaimCenter, a menudo mapeando events específicos del system o status changes a nombres de activity estandarizados. Ejemplos Siniestro CreadoDecisión de Responsabilidad TomadaPago EmitidoSiniestro Cerrado | |||
Ajustador Asignado AssignedAdjuster | El nombre o ID del usuario asignado para gestionar el siniestro o una actividad específica. | ||
Descripción Este atributo identifica al ajustador de siniestros individual responsable de un siniestro en un momento dado. Un ajustador puede ser asignado a todo el siniestro o a tareas específicas dentro de este. El análisis por Ajustador Asignado es fundamental para el equilibrio de la carga de trabajo, la gestión del rendimiento y la identificación de oportunidades de capacitación. Ayuda a responder preguntas como: '¿Qué ajustadores tienen la mayor carga de casos?', '¿Existen variaciones de rendimiento entre los ajustadores?' y '¿Está el trabajo distribuido de manera uniforme?'. Por qué es importante Registra la participación del user, lo que permite el workload analysis, performance comparison y la identificación de bottlenecks relacionados con los recursos. Dónde obtener Disponible en la entidad de Reclamo o Exposición en ClaimCenter, a menudo vinculado al objeto Usuario (p. ej., Claim.Assignee). Ejemplos j.doem.smiths.jones | |||
Causa de la Pérdida LossCause | El motivo o la causa específica del evento de pérdida (ej. Colisión, Incendio, Daños por Agua). | ||
Descripción Este atributo proporciona un contexto detallado sobre el motivo por el cual se presentó el siniestro. La causa de la pérdida a menudo dicta los pasos de investigación requeridos, el tipo de expertos necesarios y la complejidad general del siniestro. El análisis del proceso por Causa de la Pérdida puede revelar patrones ocultos. Por ejemplo, los siniestros relacionados con 'Daños por Agua' podrían tener una tasa de retrabajo más alta o requerir una mayor participación de especialistas en comparación con los siniestros por 'Robo'. Estos insights ayudan a crear procedimientos de manejo más especializados y eficientes. Por qué es importante Proporciona contexto sobre la naturaleza del siniestro, permitiendo analizar cómo las diferentes causas de pérdida impactan el flujo y la duración del proceso. Dónde obtener Este es un field estándar en la entidad Claim, generalmente llamado 'LossCause'. Ejemplos ColisiónIncendioDaños por AguaRobo | |||
Estado del Siniestro ClaimStatus | El estado general del siniestro en el momento del evento (ej. Abierto, Cerrado, Denegado). | ||
Descripción Este atributo refleja el estado de alto nivel del siniestro. Los estados clave incluyen 'Abierto', 'Cerrado', 'Denegado' y 'Reabierto'. El estado final de un siniestro es una métrica de resultado crítica. El seguimiento de los cambios en el Estado del Siniestro ayuda a definir los hitos y resultados clave del proceso. Se utiliza para identificar la resolución final de un siniestro, calcular las tasas de rechazo y analizar la frecuencia con la que los siniestros se reabren después del cierre, lo que a menudo indica problemas en el proceso o insatisfacción del cliente. Por qué es importante Indica el desenlace de un siniestro, lo cual es esencial para analizar las tasas de rechazo, los patrones de cierre y la frecuencia de reapertura de siniestros. Dónde obtener Este es un campo esencial de la entidad Claim, generalmente llamado 'State' o 'Status'. Ejemplos AbiertaCerradoDenegadoReabierto | |||
Tipo de Siniestro ClaimType | La categoría del siniestro de seguro, como Automóvil, Propiedad o Responsabilidad Civil. | ||
Descripción El Tipo de Siniestro es una categorización fundamental de un siniestro basada en la línea de negocio o la naturaleza de la pérdida. Diferentes tipos de siniestro a menudo siguen procesos distintos, tienen diferentes niveles de complejidad y están sujetos a diversas regulaciones. Segmentar el análisis de procesos por Tipo de Siniestro es fundamental para obtener insights significativos. Permite comparar el rendimiento de los procesos en las distintas líneas de negocio, identificar cuellos de botella específicos de cada tipo y adaptar las iniciativas de mejora de procesos a las características únicas de cada categoría de siniestro. Por qué es importante Permite la segmentación de reclamos, ya que diferentes tipos (p. ej., Automóvil vs. Propiedad) a menudo siguen procesos distintos y tienen diferentes objetivos de rendimiento. Dónde obtener Derivado de la entidad de Póliza o Siniestro en ClaimCenter, a menudo basado en el código de Línea de Negocio (LOB). Ejemplos Automóvil ParticularPropiedad ComercialResponsabilidad Civil GeneralCompensación Laboral | |||
Departamento Department | La unidad de negocio o departamento responsable de gestionar la actividad del siniestro. | ||
Descripción Este atributo indica el departamento o equipo al que pertenece el ajustador asignado, como 'Siniestros de Automóviles', 'Siniestros de Propiedad' o 'Unidad de Investigaciones Especiales'. Proporciona un contexto organizacional para el proceso. El análisis por Departamento es crucial para comprender el rendimiento del proceso a nivel organizacional. Ayuda a identificar retrasos en traspasos interdepartamentales, comparar la eficiencia entre equipos y asignar recursos de manera más efectiva en toda la organización de siniestros. Por qué es importante Proporciona contexto organizacional, permitiendo el análisis de rendimiento entre diferentes equipos y destacando los problemas de traspaso interdepartamental. Dónde obtener Esta información suele estar asociada al perfil del user o grupo asignado dentro de ClaimCenter. Ejemplos División de Reclamos de AutomóvilesUnidad de Siniestros PatrimonialesUnidad de Investigaciones Especiales (SIU) | |||
Es Automatizado IsAutomated | Un indicador que señala si una actividad fue realizada automáticamente por el sistema o por un usuario humano. | ||
Descripción Este atributo booleano distingue entre actividades ejecutadas por un sistema (por ejemplo, creación automática de reservas, correspondencia generada por el sistema) y aquellas realizadas manualmente por un ajustador. Analizar este atributo es clave para comprender el nivel de automatización en el proceso de siniestros. Ayuda a identificar puntos críticos de intervención manual, medir la efectividad de las iniciativas de procesamiento directo y encontrar nuevas oportunidades de automatización al señalar tareas repetitivas y basadas en reglas que actualmente son realizadas por humanos. Por qué es importante Distingue entre actividades impulsadas por el sistema y actividades realizadas por humanos, clave para el análisis de automatización y la identificación de cuellos de botella manuales. Dónde obtener Esto a menudo necesita ser derivado. Por ejemplo, los events registrados por un user genérico de 'system' pueden ser marcados como automated. Ejemplos truefalse | |||
Es Retrabajo IsRework | Un indicador que señala si una actividad representa un ciclo de retrabajo, es decir, un retorno a una etapa previa del proceso. | ||
Descripción Este atributo calculado identifica actividades que forman parte de un ciclo de retrabajo o reprocesamiento. Por ejemplo, si el proceso regresa de 'Investigation Completed' a 'Investigation Started', la segunda actividad de 'Investigation Started' se marcará como retrabajo. Detectar el retrabajo es fundamental para identificar ineficiencias y problemas de calidad en los procesos. El dashboard de 'Frecuencia de Retrabajo y Rechazo' utiliza esta métrica para cuantificar con qué frecuencia los claims se desvían de la 'ruta ideal'. Analizar las causas del retrabajo puede generar mejoras significativas en la calidad y velocidad del proceso. Por qué es importante Destaca las ineficiencias del proceso y los problemas de calidad al identificar explícitamente las actividades que forman parte de un ciclo de reelaboración. Dónde obtener Esto se calcula dentro de la herramienta de process mining al analizar la secuencia de activities para cada case. Ejemplos truefalse | |||
Estado de Jurisdicción JurisdictionState | El estado o la jurisdicción que rige el siniestro, el cual dicta los requisitos regulatorios. | ||
Descripción Este atributo especifica la jurisdicción legal (por ejemplo, el estado de EE. UU.) bajo la cual se está tramitando el siniestro. Las regulaciones de seguros pueden variar significativamente entre jurisdicciones, impactando los pasos de proceso requeridos, los plazos de comunicación y la documentación. Este es un atributo vital para el monitoreo del cumplimiento. Analizar el proceso por jurisdicción asegura que se cumplan los requisitos reglamentarios específicos de cada estado. También puede explicar variaciones en los tiempos de ciclo o en las rutas del proceso que están impulsadas por restricciones legales y no por ineficiencia operativa. Por qué es importante Crucial para el análisis de cumplimiento, ya que diferentes jurisdicciones tienen regulaciones distintas que afectan al proceso de siniestros. Dónde obtener Un campo estándar en la entidad de Reclamo, típicamente llamado 'JurisdictionState'. Ejemplos CANYTXFL | |||
Estado de SLA SLAState | Indica si el siniestro se cerró dentro de su fecha objetivo de resolución. | ||
Descripción Este atributo calculado ofrece un estado categórico del cumplimiento de los SLA para cada claim cerrado. Se obtiene comparando el timestamp de la actividad 'Claim Closed' con la 'Resolution Target Date'. Este atributo es un pilar fundamental para el dashboard de 'Cumplimiento del Objetivo de Resolución de Claims', ya que simplifica el análisis en categorías claras como 'On Time' o 'Late'. Facilita el filtrado y la agregación para calcular la tasa global de cumplimiento de SLA y para desglosar las razones de los delays. Por qué es importante Proporciona un resultado claro y categórico para el cumplimiento del SLA, facilitando la filtración, agregación y análisis del rendimiento a tiempo. Dónde obtener Campo calculado: IF (ActualCloseDate <= ResolutionTargetDate, 'A Tiempo', 'Retrasado'). Ejemplos A TiempoRetrasado | |||
Fecha del Siniestro LossDate | La fecha en la que ocurrió el incidente o la pérdida que desencadenó el siniestro. | ||
Descripción La Fecha de Siniestro es la fecha del evento real (ej. accidente automovilístico, daño a la propiedad) por el cual se presenta el siniestro. Esta es distinta de la fecha en que se reportó o creó el siniestro. El desfase temporal entre la Fecha de Siniestro y la actividad 'Siniestro Creado' (conocido como retraso de reporte) es un KPI importante. Analizar esto puede proporcionar insights sobre el comportamiento del cliente y la efectividad de los canales de primera notificación de siniestro. Por qué es importante Proporciona contexto crucial sobre el origen del siniestro y ayuda a analizar el retraso en el reporte (tiempo desde el incidente hasta la presentación del siniestro). Dónde obtener Este es un campo de fecha fundamental en la entidad Claim, a menudo llamado 'LossDate'. Ejemplos 2023-05-102023-04-202023-05-28 | |||
Fecha Objetivo de Resolución ResolutionTargetDate | La fecha en la que se espera que el siniestro sea resuelto según los SLA internos o regulatorios. | ||
Descripción La Fecha Objetivo de Resolución es una fecha límite establecida para el cierre de un siniestro, a menudo determinada por factores como la jurisdicción, el tipo de siniestro y los términos de la póliza. Sirve como un punto de referencia para medir el rendimiento y el cumplimiento. Este atributo es crítico para construir dashboards y KPIs de cumplimiento de SLA. Al comparar la fecha real de 'Siniestro Cerrado' con esta fecha objetivo, el análisis puede marcar automáticamente los siniestros atrasados, medir las tasas de rendimiento a tiempo e identificar qué tipos de siniestros o departamentos tienen dificultades para cumplir sus objetivos. Por qué es importante Este es el parámetro de referencia para medir el cumplimiento de los Service Level Agreement (SLA) y para identificar los claims en riesgo de sufrir delays. Dónde obtener Este puede ser un custom field o derivado según las business rules configuradas en ClaimCenter, posiblemente relacionado con metrics de claim específicas. Ejemplos 2023-06-142023-07-202023-08-28 | |||
Hora de Finalización EndTime | El timestamp que indica cuándo se completó una actividad. | ||
Descripción La Hora de Finalización marca la culminación de una actividad, especialmente para tareas con una duración medible, como 'Investigación' o 'Revisión de Documentos'. Aunque muchas actividades de Process Mining son instantáneas (el StartTime es suficiente), las actividades con un inicio y fin distintos se representan mejor con ambos timestamps. Este atributo permite el cálculo preciso del tiempo de procesamiento de la actividad, distinto del tiempo de espera. Ayuda a identificar qué tareas específicas consumen mucho tiempo, en lugar de solo observar largos retrasos entre diferentes pasos. Por qué es importante Permite medir con precisión cuánto tiempo lleva completar una actividad, separando el tiempo de procesamiento del tiempo de espera. Dónde obtener Esto puede necesitar ser derivado al encontrar un event posterior que concluya lógicamente la activity (por ejemplo, un status change de 'In Progress' a 'Completed'). Ejemplos 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
Monto del Pago PaymentAmount | El monto real de dinero pagado por una actividad de pago. | ||
Descripción Este atributo registra el valor de cada pago individual realizado contra un siniestro. Un único siniestro puede tener múltiples pagos a lo largo de su ciclo de vida. Esto es esencial para el análisis financiero dentro del contexto de Process Mining. Se puede usar para rastrear el desembolso total por siniestro, analizar los tiempos de aprobación de pagos según el monto y vincular las ineficiencias del proceso con los resultados financieros. Por ejemplo, los siniestros con largos tiempos de ciclo podrían correlacionarse con pagos totales más altos. Por qué es importante Registra las financial transactions dentro de un claim, permitiendo el análisis de los payment values y su relación con las actividades del proceso. Dónde obtener Se encuentra en entidades relacionadas con pagos vinculadas al siniestro, a menudo en una tabla de transacciones o cheques. Ejemplos 4500.00125000.00500.00 | |||
Monto Reclamado ClaimedAmount | El monto total reclamado inicialmente por el asegurado. | ||
Descripción Este atributo representa el valor de la pérdida tal como lo informa el reclamante. A menudo es una estimación inicial que puede cambiar a medida que se investiga el siniestro y se establecen las reservas. El análisis del Monto Reclamado ayuda a segmentar los siniestros por impacto financiero. Los siniestros de alto valor a menudo siguen un proceso más riguroso y complejo que los de bajo valor. Comparar el proceso para diferentes rangos de valor puede revelar oportunidades para agilizar el manejo de siniestros más pequeños o aplicar controles más estrictos para los más grandes. Por qué es importante Permite segmentar los reclamos por valor financiero, ya que los reclamos de alto valor pueden seguir procesos diferentes y más complejos. Dónde obtener Esta información podría no ser un campo único, sino que se puede derivar de las estimaciones iniciales de pérdidas registradas en las exposiciones. Ejemplos 5000.00150000.00750.50 | |||
Sistema de Origen SourceSystem | El sistema del cual se extrajeron los datos. | ||
Descripción Este atributo identifica el origen de los datos del evento. En un entorno empresarial moderno, los eventos relacionados con siniestros pueden originarse de múltiples sistemas, como un sistema central tipo Guidewire, un sistema de gestión documental o un portal del cliente. Especificar el sistema de origen es crucial para la gobernanza de datos, la resolución de problemas de inconsistencias de datos y la comprensión del panorama tecnológico del proceso. Ayuda a diferenciar entre los pasos centrales del proceso y las actividades de soporte de sistemas periféricos. Por qué es importante Identifica el origen de los datos, lo cual es crucial para el gobierno de datos y para los análisis que involucran múltiples sistemas integrados. Dónde obtener Este suele ser un valor estático que se añade durante el proceso de data extraction, transformation, and loading (ETL). Ejemplos Guidewire ClaimCenter v10API del Portal del ClienteDocumentum | |||
Solicitud de Información Repetida RepeatedInfoRequestFlag | Un indicador que señala si se ha solicitado 'Información Adicional' más de una vez para el mismo reclamo. | ||
Descripción Este flag booleano se establece en true si un siniestro tiene más de una actividad de 'Solicitud de Información Adicional'. Este escenario a menudo señala ineficiencias en la fase inicial de recopilación de información. Este atributo apoya directamente el KPI de 'Tasa de Solicitudes de Información Repetidas'. Ayuda a cuantificar el problema de la investigación inicial incompleta, que puede conducir a retrasos significativos y frustración del cliente. Analizar los siniestros con este flag puede ayudar a mejorar las listas de verificación y los procedimientos para los ajustadores a fin de garantizar que toda la información necesaria se solicite de una sola vez. Por qué es importante Identifica ineficiencias donde la recopilación de información no se realiza de forma exhaustiva la primera vez, lo que genera retrasos en el proceso y reelaboración. Dónde obtener Calculado dentro de la herramienta de process mining contando las ocurrencias de la actividad 'Información Adicional Solicitada' por caso. Ejemplos truefalse | |||
Tiempo de Procesamiento ProcessingTime | La duración del tiempo invertido activamente en una actividad. | ||
Descripción El Tiempo de Procesamiento mide el tiempo en que una actividad se trabaja activamente, calculado como la diferencia entre su Hora de Finalización y Hora de Inicio. Esto es distinto del tiempo de ciclo, que incluye los períodos de espera. Esta métrica calculada es vital para el análisis del rendimiento, ya que aísla el esfuerzo real requerido para una tarea del tiempo de inactividad o espera. Ayuda a identificar con precisión qué pasos son realmente lentos y dónde se pueden lograr ganancias de eficiencia mediante capacitación, mejores herramientas o rediseño de procesos. Por qué es importante Mide el tiempo de trabajo activo para una actividad, ayudando a distinguir el tiempo de valor añadido del tiempo de espera. Dónde obtener Campo calculado: EndTime - StartTime. Requiere que ambos timestamps estén disponibles en los datos de origen. Ejemplos PT8HPT15MP2D | |||
Tipo de Póliza PolicyType | El tipo específico de póliza de seguro bajo la cual se presentó el siniestro. | ||
Descripción El Tipo de Póliza proporciona una clasificación más granular que el Tipo de Siniestro, detallando el producto de seguro específico, como 'Seguro de Hogar', 'Automóvil Comercial' o 'Ciberseguro'. Este nivel de detalle puede revelar variaciones en los procesos vinculadas a productos específicos. Analizar el proceso por Tipo de Póliza ayuda a descubrir ineficiencias específicas de cada producto. Por ejemplo, los siniestros de una póliza recién lanzada podrían seguir un proceso menos maduro, lo que generaría retrasos. Este análisis puede informar el diseño de productos y los esfuerzos de estandarización de procesos. Por qué es importante Permite el análisis de procesos para productos de seguros específicos, ayudando a identificar variaciones en la gestión basadas en las particularidades de la póliza. Dónde obtener Esta información se encuentra en la entidad Policy, la cual está vinculada al Claim. Ejemplos Seguro Multirriesgo de HogarResponsabilidad Civil de Vehículos ComercialesMarítimo Interior | |||
Última Actualización de Datos LastDataUpdate | El timestamp que indica la última vez que se actualizaron o extrajeron los datos del sistema de origen. | ||
Descripción Este atributo proporciona el timestamp de la extracción de datos más reciente del sistema de origen. Es un campo de metadatos esencial para comprender la actualidad del análisis. Los dashboards y análisis deben mostrar esta información de forma destacada para que los usuarios sean conscientes de la vigencia de los datos. Ayuda a evaluar si los conocimientos reflejan el estado actual de las operaciones o se basan en datos más antiguos. Por qué es importante Indica la vigencia de los datos, asegurando que los usuarios comprendan lo actualizado que está el análisis del proceso. Dónde obtener Este valor se genera y almacena durante el proceso ETL, representando el timestamp de la data load. Ejemplos 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
Actividades de Procesamiento de Siniestros
| Actividad | Descripción | ||
|---|---|---|---|
Exposición Creada | Esta actividad significa la creación de una exposición, que representa una responsabilidad potencial específica o un tipo de pérdida bajo el siniestro (por ejemplo, daños al vehículo, lesiones). Este es un evento explícito en Guidewire. | ||
Por qué es importante Las exposiciones son fundamentales para la segmentación y el análisis de siniestros. Rastrear su creación ayuda a comprender las variaciones del proceso basándose en la complejidad del siniestro y el tipo de pérdida. Dónde obtener Capturado del CreateTime de un nuevo registro en la tabla cc_exposure. Cada registro está vinculado a un único Claim ID. Capturar Identificar la marca de tiempo (timestamp) de creación de un nuevo registro en la tabla de entidad Exposure. Tipo de evento explicit | |||
Pago Aprobado | Representa la aprobación formal de un pago de liquidación. Este es un evento de auditoría crítico y se captura explícitamente cuando un usuario con autoridad aprueba la transacción. | ||
Por qué es importante Este hito clave desbloquea el paso de payment final. Analizar el tiempo antes y después de esta activity ayuda a aislar los retrasos causados por los workflows de aprobación o la disponibilidad de los managers. Dónde obtener Este suele ser un event explícito registrado en la tabla cc_history relacionado con una entidad cc_check o cc_transaction, que anota un cambio de status de 'Pending Approval' a 'Approved'. Capturar Seguir el event de status change a 'Approved' para una payment transaction específica. Tipo de evento explicit | |||
Pago Emitido | Esta actividad marca el paso final en el proceso de pago, donde el pago se emite oficialmente y se envía al sistema financiero. Se trata de una transacción financiera explícita y registrada. | ||
Por qué es importante Esta actividad es crucial para medir la eficiencia del proceso de desembolso de pagos. Ayuda a diferenciar entre los retrasos en la aprobación y los retrasos en la emisión de fondos. Dónde obtener Capturado del IssueDate o un cambio de estado a 'Issued' o 'Submitted' en la entidad cc_check o cc_transaction. Esto suele ser un event explícito con timestamp. Capturar Identificar la IssueDate o la marca de tiempo (timestamp) del cambio de estado a 'Issued' en el registro de pago. Tipo de evento explicit | |||
Reserva Inicial Establecida | Marca la creación de la primera transacción de reserva financiera para un riesgo, estimando el costo potencial del siniestro. Este es un evento financiero crítico y se registra explícitamente. | ||
Por qué es importante Este hito es clave para el análisis financiero y para comprender la rapidez con la que se evalúa la liability potencial. Los retrasos pueden impactar la financial planning y el reporting. Dónde obtener Este event se registra con la creación del primer registro cc_reserveline asociado a una exposición en el claim. El CreateTime de la transaction es el event timestamp. Capturar Encuentre el timestamp de creación mínimo de todas las líneas de reserva para las exposiciones de un siniestro dado. Tipo de evento explicit | |||
Siniestro Cerrado | Marca el cierre exitoso de un siniestro después de que todas las actividades y pagos se han completado. Este es el evento final exitoso principal, inferido de un cambio en el estado principal del siniestro. | ||
Por qué es importante Como evento final principal, esta actividad es esencial para calcular el tiempo de ciclo de principio a fin y medir el cumplimiento de los SLA. Significa la finalización del ciclo de vida del reclamo. Dónde obtener Inferido a partir de un cambio en el campo State de la tabla cc_claim a 'Closed'. La marca de tiempo (timestamp) del evento es la CloseDate en el registro del siniestro. Capturar Identificar cuándo el campo de estado maestro del siniestro se actualiza a 'Closed'. Tipo de evento inferred | |||
Siniestro Creado | Esta actividad marca el primer aviso de siniestro (FNOL) y la creación oficial de un nuevo registro de siniestro en Guidewire ClaimCenter. Se captura explícitamente cuando una nueva entidad de siniestro se guarda en la base de datos por primera vez. | ||
Por qué es importante Como evento de inicio principal, esta actividad es esencial para medir el tiempo de ciclo completo del reclamo. Proporciona la base para todos los KPI de rendimiento y duración posteriores. Dónde obtener Este es un event explícito registrado desde el CreateTime de la tabla cc_claim. La creación de un nuevo record con un Claim ID único sirve como disparador del event. Capturar Identificar la marca de tiempo (timestamp) de creación del nuevo registro en la tabla de entidad base Claim. Tipo de evento explicit | |||
Siniestro Denegado | Representa la decisión final de denegar un siniestro, sirviendo como punto final del proceso. Este evento se infiere del cambio de estado del siniestro a 'Cerrado' con un motivo de 'Denegado'. | ||
Por qué es importante Este es un event de resultado crítico. Analizar la frecuencia, las razones y las rutas del proceso que conducen a las denegaciones ayuda a identificar problemas en la recepción del claim, la investigación o la interpretación de la policy. Dónde obtener Inferido a partir de un cambio en el campo State de la tabla cc_claim a 'Closed', combinado con el campo CloseReason siendo 'Denied' o un valor similar. La marca de tiempo (timestamp) del evento es la CloseDate. Capturar Filtre los cambios de estado de siniestro a "Cerrado" donde el código de motivo indique denegación. Tipo de evento inferred | |||
Decisión de Responsabilidad Tomada | Significa el punto en el que se ha determinado una decisión sobre la responsabilidad o la culpa para una exposición. Este evento se infiere típicamente de un cambio de estado en la entidad Exposición. | ||
Por qué es importante Este es un hito de decisión crítico que da paso a las fases de settlement y payment. Analizar el tiempo hasta esta decisión ayuda a identificar bottlenecks en las etapas de investigación y evaluación. Dónde obtener Inferido de la tabla cc_history al rastrear un cambio en el campo State o un campo de estado de responsabilidad personalizado en la entidad cc_exposure. La marca de tiempo (timestamp) del registro de historial indica la hora del evento. Capturar Monitorear los registros de auditoría o las tablas de historial en busca de actualizaciones en el estado del riesgo o el estatus de responsabilidad. Tipo de evento inferred | |||
Información Adicional Recibida | Marca la finalización de una solicitud de información adicional. Esto se registra cuando la 'Actividad' (tarea) correspondiente a la solicitud de información se marca como 'Completada'. | ||
Por qué es importante Este es el endpoint para el KPI de 'Additional Info Gathering Cycle Time'. Las duraciones prolongadas entre la solicitud y la recepción son fuentes comunes de retraso en el proceso de claims. Dónde obtener Capturado del CloseTime de un registro cc_activity donde el ActivityPattern se relaciona con una solicitud de información. El estado de la actividad debe ser 'Completed'. Capturar Identificar la marca de tiempo (timestamp) de finalización de una tarea para solicitar información externa. Tipo de evento explicit | |||
Información Adicional Solicitada | Representa una solicitud enviada al reclamante o a un tercero para obtener más información o documentación. Esto se registra típicamente como una 'Actividad' (tarea) explícita creada en ClaimCenter. | ||
Por qué es importante Esta actividad es el punto de partida para medir el KPI de 'Tiempo de Ciclo de Recopilación de Información Adicional'. Las ocurrencias frecuentes pueden indicar procesos de Primer Aviso de Siniestro (FNOL) incompletos o una recopilación de información ineficiente. Dónde obtener Capturado del CreateTime de un registro cc_activity donde el ActivityPattern está relacionado con la solicitud de documentación o información a una parte externa. Capturar Identificar la creación de una tarea para solicitar información externa. Tipo de evento explicit | |||
Investigación Iniciada | Indica el inicio formal de la fase de investigación para un siniestro o exposición. Esto se infiere a menudo de la creación de la primera 'Activity' (tarea) relacionada con la investigación en Guidewire. | ||
Por qué es importante Esta actividad marca el inicio de una fase clave, a menudo prolongada. Analizar el tiempo hasta que comienza la investigación y la duración de la investigación en sí revela importantes cuellos de botella. Dónde obtener Inferido del CreateTime de un registro cc_activity donde el ActivityPattern está relacionado con la investigación (por ejemplo, 'Initial Investigation', 'Contact Witness'). Capturar Identificar la primera creación de una tarea con un patrón o asunto relacionado con la investigación. Tipo de evento inferred | |||
Liquidación Calculada | Esta actividad representa el punto en el que se ha determinado un monto de liquidación, pero aún no ha sido aprobado para el pago. Puede inferirse de la creación de un pago en estado de 'Aprobación Pendiente'. | ||
Por qué es importante Marca la transición de la evaluación al pago. Es el punto de partida para medir el KPI de 'Tiempo de Autorización de Pagos', revelando retrasos en la cadena de aprobación. Dónde obtener Inferido del CreateTime de un registro cc_check o cc_transaction donde su estado inicial es 'Pending Approval' o un estado similar antes de 'Approved'. Capturar Identificar la creación de un registro de pago o transacción en un estado preaprobado. Tipo de evento inferred | |||
Siniestro Asignado | Representa la asignación de un siniestro a un usuario específico (ajustador) o grupo para su gestión. Esto se infiere típicamente monitoreando los cambios en los campos de asignación en la entidad Siniestro. | ||
Por qué es importante Monitorizar las asignaciones es crucial para analizar la carga de trabajo de los peritos, identificar bottlenecks en el routing y medir el time-to-first-action por parte del handler asignado. Dónde obtener Inferido de la tabla cc_history al rastrear cambios en los campos AssignedUser o AssignedGroup asociados con un ID de siniestro específico. La marca de tiempo (timestamp) del cambio indica cuándo ocurrió el evento. Capturar Monitorear los registros de auditoría o las tablas de historial en busca de actualizaciones en los campos de asignación de siniestros. Tipo de evento inferred | |||
Siniestro Reabierto | Representa un siniestro que pasa de estado 'Cerrado' a 'Abierto' nuevamente para realizar trabajo adicional. Este evento se infiere de una secuencia específica de cambios de estado. | ||
Por qué es importante Esta actividad indica retrabajo. Un alto volumen de siniestros reabiertos señala problemas con la liquidación inicial, daños no detectados u otras fallas en el proceso, lo que conlleva a un aumento de costos e ineficiencia. Dónde obtener Inferido de la tabla cc_history al identificar un cambio en el campo State de la entidad cc_claim de 'Closed' a 'Open' o a otro estado activo. Capturar Monitorear el campo de estado principal del siniestro para una transición de un estado cerrado a uno abierto. Tipo de evento inferred | |||
Guías de Extracción
Pasos
- Verificación de requisitos previos: Confirme que cuenta con los permisos y credenciales necesarios para acceder a la base de datos del data mart de Guidewire DataHub / InfoCenter con privilegios de lectura. Asegúrese de que los trabajos ETL que alimentan el data mart de reclamos estén ejecutándose correctamente y que los datos estén actualizados.
- Conexión a la base de datos: Utilice un cliente SQL estándar (como DBeaver, SQL Server Management Studio o herramientas similares) para establecer una conexión con el servidor de la base de datos del data mart.
- Exploración del esquema: Antes de ejecutar la consulta completa, familiarícese con el esquema del data mart. Identifique las tablas principales para reclamos, exposiciones, actividades y transacciones financieras. Las tablas clave suelen nombrarse con sufijos como _dim (dimensión) y _fact (hecho). Esto le ayudará a validar los nombres de tablas y columnas de marcadores de posición en el script proporcionado.
- Preparación de la consulta SQL: Copie el script SQL completo proporcionado en la sección query en el editor de consultas de su cliente SQL.
- Personalización de marcadores de posición: Revise cuidadosamente el script y reemplace todos los valores de marcadores de posición. Esto incluye el nombre de la base de datos/esquema (p. ej., [YourDataMart]), los parámetros de rango de fechas ('[StartDate]', '[EndDate]') y cualquier valor de configuración específico del sistema (p. ej., patrones de actividad, códigos de estado).
- Ejecución de la consulta: Ejecute la consulta SQL modificada en el data mart. El tiempo de ejecución puede variar según el rango de fechas seleccionado y el volumen de datos en su sistema.
- Revisión inicial de datos: Una vez completada la consulta, inspeccione los primeros cientos de filas del conjunto de resultados. Verifique que las columnas ClaimID, ActivityName, y EventTime estén pobladas como se espera y que haya diferentes tipos de actividad presentes.
- Exportar a CSV: Exporte todo el conjunto de resultados de su cliente SQL a un archivo CSV. Asigne un nombre descriptivo al archivo, por ejemplo, guidewire_claimcenter_event_log.csv.
- Formato para ProcessMind: Asegúrese de que el archivo CSV esté guardado con codificación UTF-8. Verifique que el archivo tenga una fila de encabezado que coincida con los alias de columna de la consulta SQL. El archivo ahora está listo para ser cargado a ProcessMind.
Configuración
- Fuente de datos: Guidewire DataHub/InfoCenter Claims Data Mart. Se trata de una base de datos dimensional y pre-agregada, diseñada para informes y análisis, independiente de la base de datos de producción de ClaimCenter en vivo.
- Autorizaciones requeridas: Acceso de solo lectura a la base de datos SQL que aloja el data mart. Necesitará un nombre de usuario, contraseña y detalles de conexión (dirección del servidor, nombre de la base de datos).
- Estado de los trabajos ETL: La precisión de esta extracción depende de la ejecución exitosa y oportuna de los trabajos ETL de Guidewire que alimentan el data mart. Verifique la hora de la última ejecución exitosa para comprender la actualización de los datos.
- Filtrado por rango de fechas: La consulta proporcionada incluye cláusulas WHERE con los marcadores de posición '[StartDate]' y '[EndDate]'. Se recomienda empezar con un rango de fechas limitado (ej. 3-6 meses) para optimizar el rendimiento. El filtro de fecha se aplica al campo CreateTime de la reclamación.
- Valores específicos de configuración: Guidewire es altamente configurable. Debe ajustar los valores en las cláusulas WHERE para que coincidan con la configuración de su organización. Esto incluye:
- Nombres de ActivityPattern (ej. 'fnol', 'investigation', 'Request additional information')
- Códigos de ClaimStatus, ExposureStatus y CloseReason (ej. 'denied', 'closed')
- Códigos de TransactionStatus (ej. 'pendingapproval', 'approved', 'issued')
- Rendimiento: Consultar tablas grandes de historial o auditoría puede ser intensivo en recursos. Se recomienda ejecutar la consulta durante horas de menor actividad para conjuntos de datos muy grandes. Asegúrese de que las columnas ClaimID o ClaimNumber estén indexadas en las tablas relevantes.
a Consulta de ejemplo sql
`sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';
`Pasos
- Verificación de requisitos previos: Confirme que cuenta con los permisos y credenciales necesarios para acceder a la base de datos del data mart de Guidewire DataHub / InfoCenter con privilegios de lectura. Asegúrese de que los trabajos ETL que alimentan el data mart de reclamos estén ejecutándose correctamente y que los datos estén actualizados.
- Conexión a la base de datos: Utilice un cliente SQL estándar (como DBeaver, SQL Server Management Studio o herramientas similares) para establecer una conexión con el servidor de la base de datos del data mart.
- Exploración del esquema: Antes de ejecutar la consulta completa, familiarícese con el esquema del data mart. Identifique las tablas principales para reclamos, exposiciones, actividades y transacciones financieras. Las tablas clave suelen nombrarse con sufijos como _dim (dimensión) y _fact (hecho). Esto le ayudará a validar los nombres de tablas y columnas de marcadores de posición en el script proporcionado.
- Preparación de la consulta SQL: Copie el script SQL completo proporcionado en la sección query en el editor de consultas de su cliente SQL.
- Personalización de marcadores de posición: Revise cuidadosamente el script y reemplace todos los valores de marcadores de posición. Esto incluye el nombre de la base de datos/esquema (p. ej., [YourDataMart]), los parámetros de rango de fechas ('[StartDate]', '[EndDate]') y cualquier valor de configuración específico del sistema (p. ej., patrones de actividad, códigos de estado).
- Ejecución de la consulta: Ejecute la consulta SQL modificada en el data mart. El tiempo de ejecución puede variar según el rango de fechas seleccionado y el volumen de datos en su sistema.
- Revisión inicial de datos: Una vez completada la consulta, inspeccione los primeros cientos de filas del conjunto de resultados. Verifique que las columnas ClaimID, ActivityName, y EventTime estén pobladas como se espera y que haya diferentes tipos de actividad presentes.
- Exportar a CSV: Exporte todo el conjunto de resultados de su cliente SQL a un archivo CSV. Asigne un nombre descriptivo al archivo, por ejemplo, guidewire_claimcenter_event_log.csv.
- Formato para ProcessMind: Asegúrese de que el archivo CSV esté guardado con codificación UTF-8. Verifique que el archivo tenga una fila de encabezado que coincida con los alias de columna de la consulta SQL. El archivo ahora está listo para ser cargado a ProcessMind.
Configuración
- Fuente de datos: Guidewire DataHub/InfoCenter Claims Data Mart. Se trata de una base de datos dimensional y pre-agregada, diseñada para informes y análisis, independiente de la base de datos de producción de ClaimCenter en vivo.
- Autorizaciones requeridas: Acceso de solo lectura a la base de datos SQL que aloja el data mart. Necesitará un nombre de usuario, contraseña y detalles de conexión (dirección del servidor, nombre de la base de datos).
- Estado de los trabajos ETL: La precisión de esta extracción depende de la ejecución exitosa y oportuna de los trabajos ETL de Guidewire que alimentan el data mart. Verifique la hora de la última ejecución exitosa para comprender la actualización de los datos.
- Filtrado por rango de fechas: La consulta proporcionada incluye cláusulas WHERE con los marcadores de posición '[StartDate]' y '[EndDate]'. Se recomienda empezar con un rango de fechas limitado (ej. 3-6 meses) para optimizar el rendimiento. El filtro de fecha se aplica al campo CreateTime de la reclamación.
- Valores específicos de configuración: Guidewire es altamente configurable. Debe ajustar los valores en las cláusulas WHERE para que coincidan con la configuración de su organización. Esto incluye:
- Nombres de ActivityPattern (ej. 'fnol', 'investigation', 'Request additional information')
- Códigos de ClaimStatus, ExposureStatus y CloseReason (ej. 'denied', 'closed')
- Códigos de TransactionStatus (ej. 'pendingapproval', 'approved', 'issued')
- Rendimiento: Consultar tablas grandes de historial o auditoría puede ser intensivo en recursos. Se recomienda ejecutar la consulta durante horas de menor actividad para conjuntos de datos muy grandes. Asegúrese de que las columnas ClaimID o ClaimNumber estén indexadas en las tablas relevantes.
a Consulta de ejemplo sql
`sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';
`Pasos
- Verificación de requisitos previos: Confirme que cuenta con los permisos y credenciales necesarios para acceder a la base de datos del data mart de Guidewire DataHub / InfoCenter con privilegios de lectura. Asegúrese de que los trabajos ETL que alimentan el data mart de reclamos estén ejecutándose correctamente y que los datos estén actualizados.
- Conexión a la base de datos: Utilice un cliente SQL estándar (como DBeaver, SQL Server Management Studio o herramientas similares) para establecer una conexión con el servidor de la base de datos del data mart.
- Exploración del esquema: Antes de ejecutar la consulta completa, familiarícese con el esquema del data mart. Identifique las tablas principales para reclamos, exposiciones, actividades y transacciones financieras. Las tablas clave suelen nombrarse con sufijos como _dim (dimensión) y _fact (hecho). Esto le ayudará a validar los nombres de tablas y columnas de marcadores de posición en el script proporcionado.
- Preparación de la consulta SQL: Copie el script SQL completo proporcionado en la sección query en el editor de consultas de su cliente SQL.
- Personalización de marcadores de posición: Revise cuidadosamente el script y reemplace todos los valores de marcadores de posición. Esto incluye el nombre de la base de datos/esquema (p. ej., [YourDataMart]), los parámetros de rango de fechas ('[StartDate]', '[EndDate]') y cualquier valor de configuración específico del sistema (p. ej., patrones de actividad, códigos de estado).
- Ejecución de la consulta: Ejecute la consulta SQL modificada en el data mart. El tiempo de ejecución puede variar según el rango de fechas seleccionado y el volumen de datos en su sistema.
- Revisión inicial de datos: Una vez completada la consulta, inspeccione los primeros cientos de filas del conjunto de resultados. Verifique que las columnas ClaimID, ActivityName, y EventTime estén pobladas como se espera y que haya diferentes tipos de actividad presentes.
- Exportar a CSV: Exporte todo el conjunto de resultados de su cliente SQL a un archivo CSV. Asigne un nombre descriptivo al archivo, por ejemplo, guidewire_claimcenter_event_log.csv.
- Formato para ProcessMind: Asegúrese de que el archivo CSV esté guardado con codificación UTF-8. Verifique que el archivo tenga una fila de encabezado que coincida con los alias de columna de la consulta SQL. El archivo ahora está listo para ser cargado a ProcessMind.
Configuración
- Fuente de datos: Guidewire DataHub/InfoCenter Claims Data Mart. Se trata de una base de datos dimensional y pre-agregada, diseñada para informes y análisis, independiente de la base de datos de producción de ClaimCenter en vivo.
- Autorizaciones requeridas: Acceso de solo lectura a la base de datos SQL que aloja el data mart. Necesitará un nombre de usuario, contraseña y detalles de conexión (dirección del servidor, nombre de la base de datos).
- Estado de los trabajos ETL: La precisión de esta extracción depende de la ejecución exitosa y oportuna de los trabajos ETL de Guidewire que alimentan el data mart. Verifique la hora de la última ejecución exitosa para comprender la actualización de los datos.
- Filtrado por rango de fechas: La consulta proporcionada incluye cláusulas WHERE con los marcadores de posición '[StartDate]' y '[EndDate]'. Se recomienda empezar con un rango de fechas limitado (ej. 3-6 meses) para optimizar el rendimiento. El filtro de fecha se aplica al campo CreateTime de la reclamación.
- Valores específicos de configuración: Guidewire es altamente configurable. Debe ajustar los valores en las cláusulas WHERE para que coincidan con la configuración de su organización. Esto incluye:
- Nombres de ActivityPattern (ej. 'fnol', 'investigation', 'Request additional information')
- Códigos de ClaimStatus, ExposureStatus y CloseReason (ej. 'denied', 'closed')
- Códigos de TransactionStatus (ej. 'pendingapproval', 'approved', 'issued')
- Rendimiento: Consultar tablas grandes de historial o auditoría puede ser intensivo en recursos. Se recomienda ejecutar la consulta durante horas de menor actividad para conjuntos de datos muy grandes. Asegúrese de que las columnas ClaimID o ClaimNumber estén indexadas en las tablas relevantes.
a Consulta de ejemplo sql
`sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';
`