Su Template de datos para la gestión de siniestros
Su Template de datos para la gestión de siniestros
- Atributos recomendados para recopilar
- Actividades clave que debe supervisar
- Guía de extracción para Guidewire ClaimCenter
Atributos de la gestión de siniestros
| Nombre | Descripción | ||
|---|---|---|---|
| Hora del evento EventTime | La fecha y hora exactas en que tuvo lugar la actividad. | ||
| Descripción Esta marca de tiempo indica el momento exacto en que se registró una actividad en el sistema. Es fundamental para todos los análisis de procesos basados en el tiempo. El orden cronológico de EventTime para un Claim ID permite reconstruir el flujo del proceso. La diferencia de tiempo entre eventos consecutivos se utiliza para calcular los tiempos de ciclo, espera y procesamiento, que son fundamentales para analizar el rendimiento, identificar cuellos de botella y supervisar los SLA. Por qué es importante Esta marca de tiempo es esencial para ordenar los eventos, calcular tiempos de ciclo y duraciones e identificar retrasos en el proceso. Dónde obtenerlo Se encuentra junto a los datos de eventos o actividades en las tablas de historial o auditoría de Guidewire ClaimCenter, normalmente en un campo como 'CreateTime' o 'UpdateTime'. Ejemplos 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
| ID del siniestro ClaimID | El identificador único de cada siniestro de seguros, que actúa como identificador principal del caso. | ||
| Descripción El Claim ID es la pieza central del análisis del proceso de gestión de siniestros, ya que identifica de forma única cada caso desde su presentación hasta el cierre. Vincula todas las actividades, documentos, pagos y comunicaciones asociados, lo que garantiza una visión completa y coherente del ciclo de vida del siniestro. En Process Mining, cada evento del conjunto de datos está vinculado a un Claim ID, lo que permite reconstruir el flujo completo del proceso. Esto es esencial para analizar los tiempos de ciclo, identificar variantes del proceso y seguir el recorrido de un siniestro entre distintos departamentos y personas encargadas de gestionarlo. Por qué es importante Es la clave fundamental que conecta todos los eventos relacionados y permite rastrear y analizar el recorrido completo de un único siniestro. Dónde obtenerlo Es una clave principal en Guidewire ClaimCenter, que normalmente se encuentra como Claim.ClaimNumber o en un campo similar de la entidad Claim principal. Ejemplos 000-123-45678000-987-65432001-456-11223 | |||
| Nombre de la actividad ActivityName | El nombre de la actividad empresarial o del evento que tuvo lugar en un momento concreto del ciclo de vida del siniestro. | ||
| Descripción Este atributo describe un paso o hito específico del proceso de gestión de siniestros, como 'Claim Created', 'Investigation Started' o 'Payment Issued'. La secuencia de estas actividades para un Claim ID determinado forma el flujo del proceso. Analizar la secuencia, la frecuencia y la duración entre actividades constituye el núcleo del Process Mining. Permite descubrir modelos de proceso, identificar cuellos de botella, detectar ciclos de retrabajo y analizar desviaciones del proceso. Por qué es importante Define los pasos del proceso, lo que permite visualizar mapas de proceso y analizar el flujo del proceso y los cuellos de botella. Dónde obtenerlo Normalmente se obtiene de las tablas de eventos o los registros de auditoría de ClaimCenter, a menudo mediante la asignación de eventos específicos del sistema o cambios de estado a nombres de actividad estandarizados. Ejemplos Siniestro creadoDecisión sobre la responsabilidad tomadaPago emitidoSiniestro cerrado | |||
| Causa del siniestro LossCause | El motivo o la causa específica del evento que provocó el daño, por ejemplo, Collision, Fire o Water Damage. | ||
| Descripción Este atributo proporciona información detallada sobre el motivo por el que se presentó el siniestro. La causa del daño suele determinar los pasos de investigación necesarios, el tipo de especialistas requeridos y la complejidad general del siniestro. Analizar el proceso por Cause of Loss puede revelar patrones ocultos. Por ejemplo, los siniestros relacionados con «Water Damage» podrían tener una mayor tasa de retrabajo o requerir una mayor participación de especialistas que los siniestros por «Theft». Estas conclusiones ayudan a crear procedimientos de gestión más especializados y eficientes. Por qué es importante Proporciona contexto sobre la naturaleza del siniestro y permite analizar cómo las distintas causas de daño afectan al flujo y la duración del proceso. Dónde obtenerlo Es un campo estándar de la entidad Claim, normalmente denominado «LossCause». Ejemplos ColisiónIncendioDaños por aguaRobo | |||
| Estado del siniestro ClaimStatus | El estado general del siniestro en el momento del evento, por ejemplo, Open, Closed o Denied. | ||
| Descripción Este atributo refleja el estado general del siniestro. Entre los estados principales se incluyen «Open», «Closed», «Denied» y «Reopened». El estado final del siniestro es una métrica de resultado fundamental. El seguimiento de los cambios en Claim Status ayuda a definir 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 suele indicar problemas del proceso o insatisfacción del cliente. Por qué es importante Indica el resultado de un siniestro, un dato esencial para analizar las tasas de rechazo, los patrones de cierre y la frecuencia de reapertura. Dónde obtenerlo Es un campo principal de la entidad Claim, normalmente denominado «State» o «Status». Ejemplos AbiertaCerradaDenegadaReabierta | |||
| Perito asignado AssignedAdjuster | El nombre o ID del usuario asignado para gestionar el siniestro o una actividad específica. | ||
| Descripción Este atributo identifica al perito responsable de un siniestro en un momento determinado. El perito puede estar asignado al siniestro completo o a tareas específicas dentro de este. Analizar los datos por perito asignado es fundamental para equilibrar la carga de trabajo, gestionar el rendimiento e identificar oportunidades de capacitación. Ayuda a responder preguntas como: «¿Qué peritos tienen la mayor carga de casos?», «¿Existen diferencias de rendimiento entre peritos?» y «¿Se distribuye el trabajo de forma equilibrada?». Por qué es importante Registra la participación de los usuarios y permite analizar la carga de trabajo, comparar el rendimiento e identificar cuellos de botella relacionados con los recursos. Dónde obtenerlo Está disponible en la entidad Claim o Exposure de ClaimCenter y suele estar vinculado al objeto User, por ejemplo, Claim.Assignee. Ejemplos j.doem.smiths.jones | |||
| Tipo de siniestro ClaimType | La categoría del siniestro de seguro, como Auto, Property o Liability. | ||
| Descripción Claim Type es una categorización fundamental del siniestro basada en la línea de negocio o en la naturaleza del daño. Los distintos tipos de siniestro suelen seguir procesos diferentes, tener distintos niveles de complejidad y estar sujetos a normativas específicas. Segmentar el análisis del proceso por Claim Type es esencial para obtener conclusiones relevantes. Permite comparar el rendimiento del proceso entre distintas líneas de negocio, identificar cuellos de botella específicos de cada tipo y adaptar las iniciativas de mejora a las características particulares de cada categoría de siniestro. Por qué es importante Permite segmentar los siniestros, ya que los distintos tipos, por ejemplo, Auto y Property, suelen seguir procesos diferentes y tener objetivos de rendimiento distintos. Dónde obtenerlo Se deriva de la entidad Policy o Claim en ClaimCenter, normalmente a partir del código Line of Business (LOB). Ejemplos Automóviles particularesBienes comercialesResponsabilidad civil generalCompensación laboral | |||
| Departamento Department | La unidad de negocio o el departamento responsable de gestionar la actividad del siniestro. | ||
| Descripción Este atributo indica el departamento o equipo al que pertenece el perito asignado, como «Auto Claims», «Property Claims» o «Special Investigations Unit». Proporciona contexto organizativo sobre el proceso. Analizar los datos por departamento es fundamental para comprender el rendimiento del proceso a nivel organizativo. Ayuda a identificar demoras en los traspasos entre departamentos, comparar la eficiencia de los equipos y asignar recursos de forma más eficaz en toda la organización de gestión de siniestros. Por qué es importante Proporciona contexto organizativo, permite analizar el rendimiento de distintos equipos y pone de relieve problemas en los traspasos entre departamentos. Dónde obtenerlo Esta información suele estar asociada al perfil del usuario o grupo asignado dentro de ClaimCenter. Ejemplos División de reclamaciones de automóvilesUnidad de reclamaciones de bienesUnidad de investigaciones especiales (SIU) | |||
| Es automática IsAutomated | 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 las actividades ejecutadas por un sistema, como la creación automática de reservas o la correspondencia generada por el sistema, y las realizadas manualmente por un perito. Analizar este atributo es clave para comprender el nivel de automatización del proceso de gestión de siniestros. Ayuda a identificar los puntos con mayor intervención manual, medir la eficacia de las iniciativas de procesamiento directo y encontrar nuevas oportunidades de automatización al localizar tareas repetitivas y basadas en reglas que actualmente realizan las personas. Por qué es importante Distingue entre actividades impulsadas por el sistema y actividades realizadas por personas, un aspecto clave para analizar la automatización e identificar cuellos de botella manuales. Dónde obtenerlo A menudo debe derivarse. Por ejemplo, los eventos registrados por un usuario genérico del sistema pueden marcarse como automatizados. Ejemplos truefalse | |||
| Es retrabajo IsRework | Indicador que señala si una actividad forma parte de un bucle de retrabajo, es decir, si representa el regreso a una etapa anterior del proceso. | ||
| Descripción Este atributo calculado marca las actividades que forman parte de un bucle de retrabajo. Por ejemplo, si el proceso pasa de «Investigation Completed» a «Investigation Started», la segunda actividad «Investigation Started» se marcaría como retrabajo. Identificar el retrabajo es fundamental para descubrir ineficiencias del proceso y problemas de calidad. El panel Rework and Rejection Frequency utiliza esta métrica para cuantificar la frecuencia con la que los siniestros se desvían del «happy path» ideal. Analizar las causas del retrabajo puede generar mejoras significativas en la calidad y la velocidad del proceso. Por qué es importante Pone de relieve las ineficiencias del proceso y los problemas de calidad al marcar explícitamente las actividades que forman parte de un bucle de retrabajo. Dónde obtenerlo Se calcula en la herramienta de Process Mining mediante el análisis de la secuencia de actividades de cada caso. Ejemplos truefalse | |||
| Estado del SLA SLAState | Indica si el siniestro se cerró dentro de la fecha objetivo de resolución. | ||
| Descripción Este atributo calculado proporciona un estado categórico del cumplimiento del SLA para cada siniestro cerrado. Se obtiene comparando la marca de tiempo de la actividad «Claim Closed» con «Resolution Target Date». Este atributo respalda directamente el panel «Claim Resolution Target Adherence» al simplificar el análisis en categorías claras como «On Time» o «Late». Permite filtrar y agregar datos fácilmente para calcular la tasa general de cumplimiento del SLA y profundizar en las causas de las demoras. Por qué es importante Proporciona un resultado categórico claro sobre el cumplimiento del SLA, lo que facilita filtrar, agregar y analizar el rendimiento dentro del plazo. Dónde obtenerlo Campo calculado: IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late'). Ejemplos A tiempoAtrasada | |||
| Fecha del siniestro LossDate | La fecha en la que ocurrió el incidente o daño que dio lugar al siniestro. | ||
| Descripción Date of Loss es la fecha del hecho real, por ejemplo, un accidente de automóvil o daños materiales, por el que se presenta el siniestro. Se diferencia de la fecha en la que el siniestro se notificó o creó. El tiempo transcurrido entre Date of Loss y la actividad «Claim Created», conocido como demora de notificación, es un KPI importante. Su análisis puede aportar información sobre el comportamiento de los clientes y la eficacia de los canales de primera notificación del siniestro. Por qué es importante Proporciona un contexto esencial sobre el origen del siniestro y ayuda a analizar la demora de notificación, es decir, el tiempo transcurrido entre el incidente y la presentación del siniestro. Dónde obtenerlo Es un campo de fecha fundamental de la entidad Claim, normalmente denominado «LossDate». Ejemplos 2023-05-102023-04-202023-05-28 | |||
| Fecha objetivo de resolución ResolutionTargetDate | La fecha en la que se espera resolver el siniestro de acuerdo con los SLA internos o normativos. | ||
| Descripción La fecha objetivo de resolución es el plazo establecido para cerrar un siniestro, que suele determinarse según factores como la jurisdicción, el tipo de siniestro y las condiciones de la póliza. Sirve como referencia para medir el rendimiento y el cumplimiento. Este atributo es fundamental para crear Dashboards y KPI de cumplimiento del SLA. Al comparar la fecha real de 'Siniestro cerrado' con esta fecha objetivo, el análisis puede marcar automáticamente los siniestros retrasados, medir las tasas de rendimiento puntual e identificar qué tipos de siniestro o departamentos tienen dificultades para alcanzar sus objetivos. Por qué es importante Es la referencia para medir el cumplimiento del Service Level Agreement (SLA) e identificar los siniestros con riesgo de retraso. Dónde obtenerlo Puede ser un campo personalizado o derivarse de reglas de negocio configuradas en ClaimCenter, posiblemente relacionadas con métricas específicas del siniestro. Ejemplos 2023-06-142023-07-202023-08-28 | |||
| Hora de finalización EndTime | Marca de tiempo que indica cuándo se completó una actividad. | ||
| Descripción End Time marca la finalización de una actividad, especialmente en tareas con una duración medible, como «Investigation» o «Document Review». Aunque muchas actividades de Process Mining son instantáneas y basta con StartTime, las actividades con un inicio y un fin diferenciados se representan mejor con ambas marcas de tiempo. Este atributo permite calcular con precisión el tiempo de procesamiento de una actividad, diferenciándolo del tiempo de espera. Ayuda a identificar qué tareas concretas consumen más tiempo, en lugar de limitarse a observar largas demoras entre distintos pasos. Por qué es importante Permite medir con precisión cuánto tarda una actividad en completarse y separar el tiempo de procesamiento del tiempo de espera. Dónde obtenerlo Es posible que deba derivarse mediante la identificación de un evento posterior que concluya lógicamente la actividad, por ejemplo, un cambio de estado de «In Progress» a «Completed». Ejemplos 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
| Importe del pago PaymentAmount | El importe real pagado en una actividad de pago. | ||
| Descripción Este atributo registra el valor de cada pago individual realizado en relación con un siniestro. Un mismo siniestro puede tener varios pagos a lo largo de su ciclo de vida. Es esencial para el análisis financiero en el contexto de Process Mining. Puede utilizarse para realizar el seguimiento del pago total por siniestro, analizar los tiempos de aprobación según el importe y relacionar las ineficiencias del proceso con los resultados financieros. Por ejemplo, los siniestros con ciclos más largos podrían estar asociados a pagos totales más elevados. Por qué es importante Registra las transacciones financieras de un siniestro y permite analizar los importes pagados y su relación con las actividades del proceso. Dónde obtenerlo Se encuentra en entidades relacionadas con Payment vinculadas al siniestro, normalmente en una tabla de transacciones o cheques. Ejemplos 4500.00125000.00500.00 | |||
| Importe reclamado ClaimedAmount | El importe monetario total reclamado inicialmente por el titular de la póliza. | ||
| Descripción Este atributo representa el valor del daño comunicado por el reclamante. A menudo es una estimación inicial que puede cambiar a medida que se investiga el siniestro y se establecen las reservas. Analizar el importe reclamado ayuda a segmentar los siniestros según su impacto financiero. Los siniestros de alto valor suelen seguir un proceso más riguroso y complejo que los de bajo valor. Comparar el proceso entre distintos rangos de importe puede revelar oportunidades para agilizar la gestión de los siniestros pequeños o aplicar controles más estrictos a los de mayor importe. Por qué es importante Permite segmentar los siniestros por valor financiero, ya que los de alto valor pueden seguir procesos diferentes y más complejos. Dónde obtenerlo Es posible que esta información no corresponda a un único campo, sino que se derive de las estimaciones iniciales de daños registradas en las exposiciones. Ejemplos 5000.00150000.00750.50 | |||
| Jurisdicción JurisdictionState | El estado o la jurisdicción que rige el siniestro y determina los requisitos normativos. | ||
| Descripción Este atributo especifica la jurisdicción legal, por ejemplo, el estado de EE. UU., en la que se gestiona el siniestro. La normativa de seguros puede variar considerablemente entre jurisdicciones y afectar a los pasos obligatorios del proceso, los plazos de comunicación y la documentación. Es un atributo esencial para supervisar el cumplimiento. Analizar el proceso por jurisdicción permite comprobar que se cumplen los requisitos normativos específicos de cada estado. También puede explicar variaciones en los tiempos de ciclo o las rutas del proceso causadas por restricciones legales y no por ineficiencias operativas. Por qué es importante Es fundamental para analizar el cumplimiento, ya que las distintas jurisdicciones tienen normativas diferentes que afectan al proceso de gestión de siniestros. Dónde obtenerlo Es un campo estándar de la entidad Claim, normalmente denominado «JurisdictionState». Ejemplos CANYTXFL | |||
| Sistema de origen SourceSystem | El sistema del que se extrajeron los datos. | ||
| Descripción Este atributo identifica el origen de los datos de eventos. En un entorno empresarial moderno, los eventos relacionados con siniestros pueden proceder de varios sistemas, como un sistema central como Guidewire, un sistema de gestión documental o un portal de clientes. Especificar el sistema de origen es fundamental para la gobernanza de datos, la resolución de incoherencias y la comprensión del panorama tecnológico del proceso. Ayuda a diferenciar los pasos principales del proceso de las actividades de apoyo procedentes de sistemas periféricos. Por qué es importante Identifica el origen de los datos, algo fundamental para la gobernanza de datos y para los análisis que implican varios sistemas integrados. Dónde obtenerlo Normalmente es un valor estático añadido durante el proceso de extracción, transformación y carga (ETL) de datos. Ejemplos Guidewire ClaimCenter v10API del portal del clienteDocumentum | |||
| Solicitud repetida de información RepeatedInfoRequestFlag | Indicador que señala si «Additional Info Requested» ocurrió más de una vez para el mismo siniestro. | ||
| Descripción Este indicador booleano se establece en true si un siniestro tiene más de una actividad «Additional Info Requested». Esta situación suele señalar ineficiencias en la fase inicial de recopilación de información. Este atributo respalda directamente el KPI «Repeated Info Request Rate». Ayuda a cuantificar el problema de una recopilación inicial de datos incompleta, que puede provocar demoras importantes y frustración en los clientes. Analizar los siniestros marcados puede ayudar a mejorar las listas de comprobación y los procedimientos de los peritos para garantizar que toda la información necesaria se solicite de una sola vez. Por qué es importante Identifica ineficiencias en la recopilación de información cuando esta no se completa correctamente a la primera, lo que provoca demoras y retrabajo. Dónde obtenerlo Se calcula en la herramienta de Process Mining contando las apariciones de la actividad «Additional Info Requested» por caso. Ejemplos truefalse | |||
| Tipo de póliza PolicyType | El tipo específico de póliza de seguro en virtud de la cual se presentó el siniestro. | ||
| Descripción Policy Type proporciona una clasificación más detallada que Claim Type y especifica el producto de seguro, como «Homeowners», «Commercial Auto» o «Cyber Liability». Este nivel de detalle puede revelar variaciones del proceso asociadas a productos concretos. Analizar el proceso por Policy Type 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 y provocar demoras. Este análisis puede orientar el diseño de productos y las iniciativas de estandarización de procesos. Por qué es importante Permite analizar el proceso de productos de seguro específicos e identificar variaciones en su gestión según las características de la póliza. Dónde obtenerlo Esta información se encuentra en la entidad Policy, vinculada a Claim. Ejemplos Multirriesgo de propietarios de viviendaResponsabilidad civil de automóviles comercialesTransporte terrestre de mercancías | |||
| Última actualización de datos LastDataUpdate | Marca de tiempo que indica cuándo se actualizaron o extrajeron por última vez los datos del sistema de origen. | ||
| Descripción Este atributo proporciona la marca de tiempo de la extracción más reciente de datos 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 las personas usuarias conozcan la vigencia de los datos. Ayuda a evaluar si las conclusiones reflejan el estado actual de las operaciones o se basan en datos antiguos. Por qué es importante Indica la actualidad de los datos y permite comprender hasta qué punto el análisis del proceso refleja la situación actual. Dónde obtenerlo Este valor se genera y almacena durante el proceso ETL y representa la marca de tiempo de la carga de datos. Ejemplos 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
Actividades de gestión de siniestros
| Actividad | Descripción | ||
|---|---|---|---|
| Exposición creada | Esta actividad indica la creación de una exposición, que representa una obligación potencial específica o un tipo de pérdida dentro del siniestro, como daños en un vehículo o lesiones. Es un evento explícito en Guidewire. | ||
| Por qué es importante Las exposiciones son fundamentales para segmentar y analizar los siniestros. Hacer un seguimiento de su creación ayuda a comprender las variaciones del proceso según la complejidad del siniestro y el tipo de pérdida. Dónde obtenerlo Se captura a partir de CreateTime de un nuevo registro en la tabla cc_exposure. Cada registro está vinculado a un único Claim ID. Recopilar Identifique la marca de tiempo de creación de un nuevo registro en la tabla de la entidad Exposure. Tipo de evento explicit | |||
| Pago aprobado | Representa la aprobación formal de un pago de liquidación. Es un evento de auditoría crítico que se captura explícitamente cuando una persona con autoridad aprueba la transacción. | ||
| Por qué es importante Este hito clave desbloquea el paso final del pago. Analizar el tiempo anterior y posterior a esta actividad ayuda a aislar los retrasos causados por los Workflows de aprobación o la disponibilidad de las personas responsables. Dónde obtenerlo A menudo es un evento explícito registrado en la tabla cc_history relacionado con una entidad cc_check o cc_transaction, que registra un cambio de estado de 'Pending Approval' a 'Approved'. Recopilar Haga un seguimiento del evento de cambio de estado a 'Approved' para una transacción de pago específica. Tipo de evento explicit | |||
| Pago emitido | Esta actividad marca el paso final del proceso de pago: el pago se emite oficialmente y se envía al sistema financiero. Es una transacción financiera explícita y registrada. | ||
| Por qué es importante Esta actividad es fundamental para medir la eficiencia del proceso de envío del pago. Ayuda a diferenciar los retrasos de aprobación de los retrasos en la emisión efectiva de los fondos. Dónde obtenerlo Se captura a partir de IssueDate o de un cambio de estado a 'Issued' o 'Submitted' en la entidad cc_check o cc_transaction. A menudo es un evento explícito con marca de tiempo. Recopilar Identifique IssueDate o la marca de tiempo del cambio de estado a 'Issued' en el registro del pago. Tipo de evento explicit | |||
| Reserva inicial establecida | Registra la creación de la primera transacción de reserva financiera para una exposición, con la estimación del coste potencial del siniestro. Es un evento financiero crítico que se captura explícitamente. | ||
| Por qué es importante Este hito es clave para el análisis financiero y para comprender con qué rapidez se evalúa la obligación potencial. Los retrasos pueden afectar a la planificación y los informes financieros. Dónde obtenerlo Este evento se captura a partir de la creación del primer registro cc_reserveline asociado a una exposición del siniestro. CreateTime de la transacción es la marca de tiempo del evento. Recopilar Busque la marca de tiempo de creación mínima de todas las líneas de reserva correspondientes a las exposiciones de un siniestro determinado. Tipo de evento explicit | |||
| Siniestro cerrado | Registra el cierre correcto de un siniestro una vez completadas todas las actividades y pagos. Es el evento final principal de éxito y se infiere a partir 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 completo y medir el cumplimiento de los SLA. Indica la finalización del ciclo de vida del siniestro. Dónde obtenerlo Se infiere a partir del cambio del campo State de la tabla cc_claim a 'Closed'. La marca de tiempo del evento es CloseDate en el registro del siniestro. Recopilar Identifique cuándo se actualiza a 'Closed' el campo de estado principal del siniestro. Tipo de evento inferred | |||
| Siniestro creado | Esta actividad registra la primera notificación del siniestro (FNOL) y la creación oficial de un nuevo registro de siniestro en Guidewire ClaimCenter. Se captura explícitamente cuando una nueva entidad Claim se guarda por primera vez en la base de datos. | ||
| Por qué es importante Como evento de inicio principal, esta actividad es esencial para medir el tiempo de ciclo completo del siniestro. Proporciona la referencia inicial para todos los KPI posteriores de rendimiento y duración. Dónde obtenerlo Este es un evento explícito capturado a partir de CreateTime de la tabla cc_claim. La creación de un nuevo registro con un Claim ID único actúa como desencadenante del evento. Recopilar Identifique la marca de tiempo de creación del nuevo registro en la tabla de la entidad Claim principal. Tipo de evento explicit | |||
| Siniestro rechazado | Representa la decisión final de rechazar un siniestro y actúa como punto terminal del proceso. Se infiere a partir del cambio del estado del siniestro a un estado cerrado con el motivo 'Denied'. | ||
| Por qué es importante Este es un evento de resultado crítico. Analizar la frecuencia, los motivos y las rutas del proceso que conducen a los rechazos ayuda a identificar problemas en la recepción del siniestro, la investigación o la interpretación de la póliza. Dónde obtenerlo Se infiere a partir del cambio del campo State de la tabla cc_claim a 'Closed', combinado con el valor 'Denied' o similar en el campo CloseReason. La marca de tiempo del evento es CloseDate. Recopilar Filtre los cambios de estado de los siniestros a 'Closed' cuyo código de motivo indique un rechazo. Tipo de evento inferred | |||
| Decisión sobre la responsabilidad tomada | Indica el momento en que se determina la responsabilidad o culpabilidad respecto a una exposición. Normalmente se infiere a partir de un cambio de estado en la entidad Exposure. | ||
| Por qué es importante Este es un hito de decisión crítico que da paso a las fases de liquidación y pago. Analizar el tiempo hasta esta decisión ayuda a identificar cuellos de botella en las etapas de investigación y evaluación. Dónde obtenerlo Se infiere de la tabla cc_history mediante el seguimiento de un cambio en State o en un campo personalizado de estado de responsabilidad de la entidad cc_exposure. La marca de tiempo del registro histórico indica el momento del evento. Recopilar Supervise los registros de auditoría o las tablas de historial para detectar actualizaciones en el estado o el estado de responsabilidad de la exposición. Tipo de evento inferred | |||
| Información adicional recibida | Registra la finalización de una solicitud de información adicional. Se captura cuando la Activity correspondiente a la solicitud de información se marca como 'Completed'. | ||
| Por qué es importante Este es el punto final del KPI 'Additional Info Gathering Cycle Time'. Los periodos prolongados entre la solicitud y la recepción son una fuente habitual de retrasos en la gestión de siniestros. Dónde obtenerlo Se captura a partir de CloseTime de un registro cc_activity cuyo ActivityPattern está relacionado con una solicitud de información. El estado de la actividad debe ser 'Completed'. Recopilar Identifique la marca de tiempo de finalización de una tarea para solicitar información externa. Tipo de evento explicit | |||
| Información adicional solicitada | Representa una solicitud enviada a la persona reclamante o a un tercero para obtener más información o documentación. Normalmente se captura como una Activity explícita, es decir, una tarea creada en ClaimCenter. | ||
| Por qué es importante Esta actividad es el punto de partida para medir el KPI 'Additional Info Gathering Cycle Time'. Su aparición frecuente puede indicar procesos FNOL incompletos o una recopilación de información ineficiente. Dónde obtenerlo Se captura a partir de CloseTime de un registro cc_activity cuyo ActivityPattern está relacionado con la solicitud de documentación o información a una parte externa. Recopilar Identifique 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 de un siniestro o una exposición. A menudo se infiere a partir de la creación de la primera Activity relacionada con la investigación en Guidewire. | ||
| Por qué es importante Esta actividad marca el inicio de una fase clave que suele ser prolongada. Analizar el tiempo transcurrido hasta el inicio de la investigación y la duración de la propia investigación permite descubrir cuellos de botella importantes. Dónde obtenerlo Se infiere de CreateTime de un registro cc_activity cuyo ActivityPattern está relacionado con la investigación, por ejemplo, 'Initial Investigation' o 'Contact Witness'. Recopilar Identifique la primera creación de una tarea cuyo patrón o asunto esté relacionado con la investigación. Tipo de evento inferred | |||
| Liquidación calculada | Esta actividad representa el momento en que se determina el importe de la liquidación, pero aún no se aprueba el pago. Puede inferirse a partir de la creación de un pago con estado 'Pending Approval'. | ||
| Por qué es importante Marca la transición de la evaluación al pago. Es el punto de partida para medir el KPI 'Payment Authorization Lead Time' y detectar retrasos en la cadena de aprobación. Dónde obtenerlo Se infiere de CreateTime de un registro cc_check o cc_transaction cuyo estado inicial sea 'Pending Approval' o un estado similar anterior a 'Approved'. Recopilar Identifique la creación de un registro de pago o transacción con un estado previo a la aprobación. Tipo de evento inferred | |||
| Siniestro asignado | Representa la asignación de un siniestro a una persona usuaria específica, como la persona encargada de ajustarlo, o a un grupo para su gestión. Normalmente se infiere mediante el seguimiento de los cambios en los campos de asignación de la entidad Claim. | ||
| Por qué es importante El seguimiento de las asignaciones es fundamental para analizar la carga de trabajo de las personas encargadas de gestionar siniestros, identificar cuellos de botella en el enrutamiento y medir el tiempo hasta la primera acción de la persona responsable. Dónde obtenerlo Se infiere de la tabla cc_history mediante el seguimiento de los cambios en los campos AssignedUser o AssignedGroup asociados a un Claim ID específico. La marca de tiempo del cambio indica cuándo ocurrió el evento. Recopilar Supervise los registros de auditoría o las tablas de historial para detectar actualizaciones en los campos de asignación del siniestro. Tipo de evento inferred | |||
| Siniestro reabierto | Representa el cambio de un siniestro del estado 'Closed' al estado 'Open' para realizar trabajo adicional. Se infiere a partir de una secuencia específica de cambios de estado. | ||
| Por qué es importante Esta actividad indica retrabajo. Un volumen elevado de siniestros reabiertos señala problemas en la liquidación inicial, daños no detectados u otros fallos del proceso, lo que aumenta los costes y reduce la eficiencia. Dónde obtenerlo Se infiere de la tabla cc_history al identificar un cambio en el campo State de la entidad cc_claim de 'Closed' a 'Open' u otro estado activo. Recopilar Supervise el campo de estado principal del siniestro para detectar 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 dispone de los permisos y las credenciales necesarios para acceder con privilegios de lectura a la base de datos del data mart de Guidewire DataHub / InfoCenter. Asegúrese de que los trabajos ETL que cargan el data mart de siniestros se ejecutan correctamente y de 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 u otra herramienta similar, para conectarse al 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 de siniestros, exposiciones, actividades y transacciones financieras. Normalmente, las tablas clave incluyen sufijos como _dim (dimensión) y _fact (hechos). Esto le ayudará a validar los nombres de tablas y columnas de ejemplo incluidos en el script.
- Preparación de la consulta SQL: Copie el script SQL completo incluido en la sección de consultas en el editor de consultas de su cliente SQL.
- Personalización de los valores de ejemplo: Revise detenidamente el script y sustituya todos los valores de ejemplo. Esto incluye el nombre de la base de datos o el esquema, por ejemplo [YourDataMart], los parámetros del intervalo de fechas ('[StartDate]', '[EndDate]') y cualquier valor de configuración específico del sistema, como los patrones de actividad o los 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 intervalo de fechas seleccionado y el volumen de datos del sistema.
- Revisión inicial de los datos: Cuando finalice la consulta, revise las primeras cientos de filas del conjunto de resultados. Compruebe que las columnas ClaimID, ActivityName y EventTime estén completas según lo esperado y que aparezcan distintos tipos de actividad.
- Exportación a CSV: Exporte todo el conjunto de resultados desde su cliente SQL a un archivo CSV. Asígnele un nombre descriptivo, por ejemplo, guidewire_claimcenter_event_log.csv.
- Formato para ProcessMind: Asegúrese de guardar el archivo CSV con codificación UTF-8. Verifique que incluya una fila de encabezados que coincida con los alias de columna de la consulta SQL. El archivo ya está listo para cargarlo en ProcessMind.
Configuración
- Fuente de datos: Data Mart de siniestros de Guidewire DataHub/InfoCenter. Se trata de una base de datos dimensional preagregada, diseñada para informes y análisis, independiente de la base de datos de producción activa de ClaimCenter.
- Autorizaciones necesarias: Acceso de solo lectura a la base de datos SQL que aloja el data mart. Necesitará un nombre de usuario, una contraseña y los datos de conexión, como la dirección del servidor y el nombre de la base de datos.
- Estado de los trabajos ETL: La precisión de esta extracción depende de que los trabajos ETL de Guidewire que cargan el data mart se ejecuten correctamente y a tiempo. Verifique la hora de la última ejecución correcta para conocer la actualidad de los datos.
- Filtrado por intervalo de fechas: La consulta proporcionada incluye cláusulas WHERE con los valores de ejemplo '[StartDate]' y '[EndDate]'. Se recomienda comenzar con un intervalo limitado, por ejemplo, de 3 a 6 meses, para controlar el rendimiento. El filtro de fechas se aplica a CreateTime del siniestro.
- Valores específicos de la configuración: Guidewire ofrece un alto nivel de configuración. Debe ajustar los valores de las cláusulas WHERE para que coincidan con la configuración de su organización. Esto incluye:
- Nombres de ActivityPattern, por ejemplo, 'fnol', 'investigation', 'Request additional information'
- Códigos de ClaimStatus, ExposureStatus y CloseReason, por ejemplo, 'denied', 'closed'
- Códigos de TransactionStatus, por ejemplo, 'pendingapproval', 'approved', 'issued'
- Rendimiento: Consultar tablas grandes de historial o auditoría puede consumir muchos recursos. Para conjuntos de datos muy grandes, se recomienda ejecutar la consulta fuera de las horas de mayor actividad. Asegúrese de que las columnas ClaimID o ClaimNumber estén indexadas en las tablas correspondientes.
a Consulta de ejemplo 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
- Confirme que su organización dispone de un recurso compartido de datos activo de Guidewire Cloud Data Access, CDA, en Snowflake para el entorno de ClaimCenter, y obtenga de su administrador de Guidewire Cloud el identificador de la cuenta de Snowflake, la base de datos, el esquema, el warehouse, el rol, el método de autenticación y la configuración de red autorizada.
- Confirme los objetos y las columnas exactos de CDA expuestos en su recurso compartido. Los esquemas y nombres de columna de CDA pueden variar según el tenant, la versión, la configuración y el modelo de intercambio de datos. Sustituya cada objeto o columna entre corchetes de la consulta por el objeto correspondiente de su entorno. No dé por hecho que los nombres de las entidades operativas de ClaimCenter se exponen sin cambios en Snowflake.
- Identifique la fuente de creación de siniestros, historial de asignaciones, creación de exposiciones, transacciones de reservas, actividades, historial de estados de exposición, historial de estados de pago e historial de estados de siniestro. Si su recurso compartido no expone tablas de historial ni registros de auditoría, configure una fuente aprobada que conserve el valor anterior, el valor nuevo, la marca de tiempo del evento y el responsable de cada transición de estado necesaria.
- Conéctese al recurso compartido de Snowflake de CDA mediante un cliente, una hoja de trabajo, un notebook o una herramienta de ejecución SQL de Snowflake autorizada. Siempre que sea posible, utilice un rol de solo lectura. Establezca en la consulta las marcas de tiempo inicial y final del análisis mediante [Start timestamp] y [End timestamp], y aplique cualquier filtro aprobado por empresa o unidad de negocio mediante [Company filter].
- Sustituya los valores de ejemplo de origen de la consulta por nombres de objetos y columnas de CDA verificados. La consulta crea explícitamente filas para las 14 actividades necesarias: Claim Created, Claim Assigned, Exposure Created, Initial Reserve Set, Investigation Started, Additional Info Requested, Additional Info Received, Liability Decision Made, Settlement Calculated, Payment Approved, Payment Issued, Claim Denied, Claim Closed y Claim Reopened.
- Ejecute la consulta y revise el esquema de resultados. La salida debe contener ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus y LossCause. ClaimID, ActivityName y EventTime son obligatorios para ProcessMind. Conserve una fila por evento y no agregue los eventos por siniestro.
- Valide las marcas de tiempo, las transiciones de estado, los cambios de asignación, la gestión de duplicados y los recuentos de actividades antes de exportar. Confirme que las marcas de tiempo de los eventos utilicen una zona horaria coherente y que varios eventos con la misma marca de tiempo permanezcan en filas separadas cuando representen actividades de negocio distintas.
- Exporte el resultado como CSV UTF-8 u otro formato tabular compatible con ProcessMind. Asigne ClaimID como identificador del caso, ActivityName como actividad y EventTime como marca de tiempo del evento. Mantenga los atributos recomendados como atributos adicionales del evento y cargue el archivo en ProcessMind sin añadir actividades inferidas fuera de esta extracción.
Configuración
- Conexión y autorización: Utilice el recurso compartido de datos de Snowflake proporcionado por Guidewire mediante una cuenta, un rol, un warehouse y una ruta de red de Snowflake autorizados. CDA es de solo lectura desde la perspectiva del consumidor. El acceso necesario depende de la configuración de su tenant y puede incluir permisos para consultar la base de datos compartida y los esquemas o las vistas específicos.
- Configuración de objetos de origen: Sustituya todas las referencias de origen entre corchetes por objetos verificados en su recurso compartido de CDA. La consulta no presupone nombres universales de tablas o columnas de ClaimCenter, ya que las estructuras expuestas varían según la versión y el tenant.
- Intervalo de fechas: Comience con un periodo de tres a seis meses para la validación y el análisis operativo. Utilice un intervalo más amplio solo después de confirmar la capacidad del warehouse, la retención del historial de eventos y una duración de consulta aceptable. Filtre los registros de origen por la marca de tiempo del evento correspondiente, no solo por la fecha de creación del siniestro, para no excluir actividades posteriores.
- Salida obligatoria: ClaimID, ActivityName y EventTime deben estar presentes y no ser nulos en cada fila de evento. ActivityName debe utilizar exactamente las etiquetas esperadas por el modelo de procesos de ProcessMind.
- Salida recomendada: Incluya AssignedAdjuster, ClaimType, ClaimStatus y LossCause. Cuando sea posible, estos valores pueden proceder de la instantánea correspondiente al momento del evento. Si solo se exponen valores del estado actual, documente esta limitación, ya que los atributos históricos podrían no reflejar el valor que tenían en el momento del evento.
- Filtros: Aplique [Company filter] solo después de confirmar la columna específica del tenant correspondiente a la empresa, la organización, la unidad de negocio o la entidad jurídica. No filtre por tipo de documento a menos que la configuración de ClaimCenter exponga un campo de tipo de documento verificado y relevante para las actividades solicitadas.
- Historial de eventos: Las asignaciones, investigaciones, solicitudes de información, decisiones de responsabilidad, estados de pago y reaperturas de siniestros requieren datos históricos o de auditoría para identificar las transiciones. Las tablas del estado actual por sí solas no permiten reconstruir de forma fiable los eventos anteriores.
- Eliminación de duplicados: Utilice un identificador de evento de origen verificado cuando esté disponible. La consulta utiliza ROW_NUMBER únicamente como medida de protección configurable. No elimine duplicados basándose solo en ClaimID y la marca de tiempo cuando puedan producirse legítimamente actividades distintas al mismo tiempo.
- Rendimiento: Limite el intervalo de fechas, seleccione únicamente las columnas necesarias, filtre cada fuente por su marca de tiempo del evento y utilice un warehouse de Snowflake con el tamaño adecuado. Para grandes volúmenes, considere materializar una vista de eventos validada o realizar una extracción incremental.
- Zona horaria: Estandarice EventTime en una única zona horaria documentada. Confirme si las marcas de tiempo de CDA se almacenan en UTC, hora local o variantes de marca de tiempo de Snowflake antes de cargar el registro de eventos.
- Requisitos previos: Confirme que el recurso compartido incluye los datos financieros, de actividades, asignaciones, exposiciones, pagos e historial de estados de ClaimCenter necesarios, y que las políticas de retención conservan las transiciones históricas requeridas.
a Consulta de ejemplo sql
WITH
params AS (
SELECT
TO_TIMESTAMP_TZ('[Start timestamp]') AS start_ts,
TO_TIMESTAMP_TZ('[End timestamp]') AS end_ts
),
claim_created AS (
SELECT
CAST(c.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Created' AS ActivityName,
CAST(c.[Claim created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(c.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(c.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(c.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(c.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(c.[Claim event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim source object] c
CROSS JOIN params p
WHERE c.[Claim created timestamp column] >= p.start_ts
AND c.[Claim created timestamp column] < p.end_ts
AND [Company filter]
),
claim_assigned AS (
SELECT
CAST(h.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Assigned' AS ActivityName,
CAST(h.[Assignment event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(h.[New assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(h.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(h.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(h.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(h.[Assignment event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim assignment history object] h
CROSS JOIN params p
WHERE h.[Assignment event timestamp column] >= p.start_ts
AND h.[Assignment event timestamp column] < p.end_ts
AND h.[New assigned adjuster column] IS DISTINCT FROM h.[Previous assigned adjuster column]
AND [Company filter]
),
exposure_created AS (
SELECT
CAST(e.[Claim ID column] AS VARCHAR) AS ClaimID,
'Exposure Created' AS ActivityName,
CAST(e.[Exposure created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(e.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(e.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(e.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(e.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(e.[Exposure event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure source object] e
CROSS JOIN params p
WHERE e.[Exposure created timestamp column] >= p.start_ts
AND e.[Exposure created timestamp column] < p.end_ts
AND [Company filter]
),
initial_reserve_set AS (
SELECT
CAST(r.[Claim ID column] AS VARCHAR) AS ClaimID,
'Initial Reserve Set' AS ActivityName,
CAST(r.[Reserve transaction timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(r.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(r.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(r.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(r.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(r.[Reserve transaction identifier column] AS VARCHAR) AS SourceEventID
FROM [Your reserve transaction source object] r
CROSS JOIN params p
WHERE r.[Reserve transaction timestamp column] >= p.start_ts
AND r.[Reserve transaction timestamp column] < p.end_ts
AND r.[Reserve transaction sequence or first reserve indicator column] = [Value identifying first reserve]
AND [Company filter]
),
investigation_started AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Investigation Started' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured investigation activity value]'
AND [Company filter]
),
additional_info_requested AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Requested' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND [Company filter]
),
additional_info_received AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Received' AS ActivityName,
CAST(a.[Activity completion timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity completion timestamp column] >= p.start_ts
AND a.[Activity completion timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND a.[Activity status column] = '[Configured completed status value]'
AND [Company filter]
),
liability_decision_made AS (
SELECT
CAST(eh.[Claim ID column] AS VARCHAR) AS ClaimID,
'Liability Decision Made' AS ActivityName,
CAST(eh.[Exposure status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(eh.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(eh.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(eh.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(eh.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(eh.[Exposure status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure status history object] eh
CROSS JOIN params p
WHERE eh.[Exposure status event timestamp column] >= p.start_ts
AND eh.[Exposure status event timestamp column] < p.end_ts
AND eh.[New exposure status column] = '[Configured liability decision status value]'
AND eh.[New exposure status column] IS DISTINCT FROM eh.[Previous exposure status column]
AND [Company filter]
),
settlement_calculated AS (
SELECT
CAST(pay.[Claim ID column] AS VARCHAR) AS ClaimID,
'Settlement Calculated' AS ActivityName,
CAST(pay.[Payment created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(pay.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(pay.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(pay.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(pay.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(pay.[Payment identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment source object] pay
CROSS JOIN params p
WHERE pay.[Payment created timestamp column] >= p.start_ts
AND pay.[Payment created timestamp column] < p.end_ts
AND pay.[Payment status column] = '[Configured pending approval status value]'
AND [Company filter]
),
payment_approved AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Approved' AS ActivityName,
CAST(ph.[Payment approval timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Approving user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment approval timestamp column] >= p.start_ts
AND ph.[Payment approval timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured approved status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
payment_issued AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Issued' AS ActivityName,
CAST(ph.[Payment issued timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Issuing user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment issued timestamp column] >= p.start_ts
AND ph.[Payment issued timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured issued status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
claim_denied AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Denied' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND ch.[Claim closure reason column] = '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_closed AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Closed' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND COALESCE(ch.[Claim closure reason column], '') <> '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_reopened AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Reopened' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[Previous claim status column] = '[Configured closed status value]'
AND ch.[New claim status column] = '[Configured open status value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
all_events AS (
SELECT * FROM claim_created
UNION ALL SELECT * FROM claim_assigned
UNION ALL SELECT * FROM exposure_created
UNION ALL SELECT * FROM initial_reserve_set
UNION ALL SELECT * FROM investigation_started
UNION ALL SELECT * FROM additional_info_requested
UNION ALL SELECT * FROM additional_info_received
UNION ALL SELECT * FROM liability_decision_made
UNION ALL SELECT * FROM settlement_calculated
UNION ALL SELECT * FROM payment_approved
UNION ALL SELECT * FROM payment_issued
UNION ALL SELECT * FROM claim_denied
UNION ALL SELECT * FROM claim_closed
UNION ALL SELECT * FROM claim_reopened
),
deduplicated_events AS (
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause,
SourceEventID,
ROW_NUMBER() OVER (
PARTITION BY ActivityName, COALESCE(SourceEventID, ClaimID || '|' || TO_VARCHAR(EventTime))
ORDER BY EventTime
) AS duplicate_rank
FROM all_events
WHERE ClaimID IS NOT NULL
AND ActivityName IS NOT NULL
AND EventTime IS NOT NULL
)
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause
FROM deduplicated_events
WHERE duplicate_rank = 1
ORDER BY ClaimID, EventTime, ActivityName; Pasos
- Confirme que el acceso directo de lectura a la base de datos operativa de Guidewire ClaimCenter local está autorizado, que la plataforma de base de datos y la versión del esquema están documentadas y que dispone de una conexión de solo lectura. No consulte la base de datos de producción sin una ventana de extracción aprobada.
- Identifique las tablas físicas y las columnas utilizadas por su implementación de ClaimCenter. Asigne las entidades de siniestros, exposiciones, actividades, asignaciones, reservas, pagos, historial de estados y usuarios o grupos a los valores de ejemplo de la consulta. Como los nombres físicos y las estructuras de auditoría varían según la implementación y la versión, sustituya cada valor de ejemplo únicamente después de validarlo en el catálogo de su base de datos y en el modelo de datos de ClaimCenter.
- Defina el periodo de extracción mediante [Start date parameter] y [End date parameter]. Utilice un solapamiento, por ejemplo, de uno o dos días antes del inicio solicitado, cuando los cambios de estado, la finalización de tareas o las transacciones financieras puedan registrarse fuera del periodo principal de creación del siniestro.
- Ejecute la instrucción SQL completa con privilegios de solo lectura. Cada actividad se genera como una fila de evento explícita. La consulta no depende de ProcessMind para inferir eventos después de la ingesta. Los eventos inferidos a partir de cambios de campos se derivan dentro de la instrucción SQL a partir de los registros de historial o auditoría correspondientes.
- Valide las asignaciones de origen de cada actividad. Confirme que la creación del siniestro utilice el primer registro Claim guardado, que la asignación utilice los cambios de asignación, que la creación de la exposición utilice los registros de creación de exposiciones, que la reserva inicial utilice la primera transacción de reserva por exposición, que la investigación y las solicitudes de información utilicen los registros de actividad, que la responsabilidad utilice la transición de estado de exposición configurada, que la liquidación utilice un estado de pago pendiente de aprobación y que la aprobación y la emisión del pago utilicen sus estados de auditoría financiera correspondientes.
- Normalice la salida con la estructura necesaria para el registro de eventos. ClaimID debe ser el identificador del caso, ActivityName debe contener exactamente uno de los catorce nombres de actividad documentados y EventTime debe ser una marca de tiempo. Conserve los atributos recomendados, incluidos AssignedAdjuster, ClaimType, ClaimStatus y LossCause, cuando la asignación de origen los proporcione.
- Revise los eventos duplicados y su orden. Si el origen contiene varias filas de auditoría para la misma transición de negocio, aplique la clave de eliminación de duplicados específica de la implementación en la expresión de tabla común correspondiente. No agrupe eventos de negocio distintos que tengan marcas de tiempo o identificadores de origen diferentes.
- Exporte el resultado como CSV UTF-8 u otro formato tabular compatible con ProcessMind. Incluya una fila de encabezados con ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus y LossCause. Asegúrese de que las marcas de tiempo incluyan información de zona horaria o utilicen de forma coherente la zona horaria documentada de la base de datos. Cargue el archivo en ProcessMind y asigne ClaimID como identificador del caso, ActivityName como actividad y EventTime como marca de tiempo del evento.
Configuración
- Acceso a la base de datos: Utilice una cuenta de solo lectura con permisos para consultar las tablas operativas, de historial, de actividades y de transacciones financieras necesarias de ClaimCenter. No conceda privilegios de escritura, modificación del esquema ni administración para la extracción.
- Asignación del esquema: Sustituya [Your claim table], [Your exposure table], [Your activity table], [Your reserve table], [Your payment table], [Your claim history table], [Your exposure history table] y los valores de ejemplo relacionados por nombres verificados en la implementación de destino. No dé por hecho que el nombre lógico de una entidad de Guidewire coincide con el nombre físico de la tabla de la base de datos.
- Intervalo de fechas: Comience con datos de tres a seis meses. Utilice [Start date parameter] y [End date parameter], e incluya un periodo de solapamiento cuando los eventos puedan registrarse después de la creación del siniestro o cuando los siniestros reabiertos abarquen varios periodos de informe.
- Filtros: Aplique [Company Code filter], [Document Type filter], la jurisdicción, la línea de negocio u otros filtros específicos de la organización solo después de confirmar sus columnas físicas y su significado empresarial. Evite excluir siniestros que no tengan pagos o exposiciones, ya que esos registros son necesarios para analizar el ciclo de vida completo.
- Nombres de actividades: Mantenga exactamente los catorce valores de ActivityName definidos en la consulta para que ProcessMind reciba etiquetas de eventos coherentes.
- Semántica de los eventos: Las actividades descritas como inferidas se generan a partir de transiciones de estado, asignación, historial o actividad de origen en SQL. ProcessMind no derivará estos eventos de otras filas después de la ingesta.
- Rendimiento: Limite el periodo de extracción, seleccione únicamente las columnas necesarias, filtre las tablas de origen antes de realizar las combinaciones y verifique los índices de los identificadores de siniestro, identificadores de exposición, marcas de tiempo de eventos, campos de estado e identificadores de transacción. Cuando esté disponible, ejecute las extracciones grandes en una réplica de informes.
- Coherencia: Utilice un nivel de aislamiento de transacciones adecuado para informes y capture un límite de extracción coherente. Evite leer las tablas mientras un lote financiero o una actualización masiva de estados se haya confirmado parcialmente.
- Zonas horarias: Documente la zona horaria de la base de datos y convierta todas las marcas de tiempo de origen a una única zona horaria acordada antes de exportar. No mezcle las marcas de tiempo locales de la aplicación con las del servidor de la base de datos.
- Requisitos previos: Confirme que los módulos de ClaimCenter necesarios, los permisos financieros, la retención de auditoría o historial y la conectividad con la base de datos estén disponibles. Si la retención del historial o la auditoría está desactivada, las actividades inferidas correspondientes no podrán reconstruirse de forma fiable.
- Configuración de validación: Registre la versión de ClaimCenter, la plataforma de base de datos, la asignación del esquema, la hora de extracción, los parámetros de fecha, los filtros y los recuentos de filas con cada exportación.
a Consulta de ejemplo sql
WITH
claim_created AS (
SELECT
c.[Claim ID column] AS ClaimID,
CAST('Claim Created' AS VARCHAR(100)) AS ActivityName,
c.[Claim Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim table] c
WHERE c.[Claim Created Timestamp column] >= [Start date parameter]
AND c.[Claim Created Timestamp column] < [End date parameter]
),
claim_assigned AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Assigned' AS VARCHAR(100)) AS ActivityName,
h.[Assignment Change Timestamp column] AS EventTime,
h.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim assignment history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Assignment Change Timestamp column] >= [Start date parameter]
AND h.[Assignment Change Timestamp column] < [End date parameter]
AND h.[Assigned Adjuster column] IS NOT NULL
),
exposure_created AS (
SELECT
e.[Claim ID column] AS ClaimID,
CAST('Exposure Created' AS VARCHAR(100)) AS ActivityName,
e.[Exposure Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure table] e
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = e.[Claim ID column]
WHERE e.[Exposure Created Timestamp column] >= [Start date parameter]
AND e.[Exposure Created Timestamp column] < [End date parameter]
),
initial_reserve_set AS (
SELECT
x.ClaimID,
CAST('Initial Reserve Set' AS VARCHAR(100)) AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
r.[Claim ID column] AS ClaimID,
r.[Reserve Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause,
ROW_NUMBER() OVER (
PARTITION BY r.[Exposure ID column]
ORDER BY r.[Reserve Timestamp column], r.[Reserve Transaction ID column]
) AS reserve_sequence
FROM [Your reserve transaction table] r
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = r.[Claim ID column]
WHERE r.[Reserve Timestamp column] >= [Start date parameter]
AND r.[Reserve Timestamp column] < [End date parameter]
) x
WHERE x.reserve_sequence = 1
),
investigation_started AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Investigation Started' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Investigation activity type value])
),
additional_info_requested AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Requested' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
),
additional_info_received AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Received' AS VARCHAR(100)) AS ActivityName,
a.[Activity Completed Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Completed Timestamp column] >= [Start date parameter]
AND a.[Activity Completed Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
AND a.[Activity Status column] = [Completed activity status value]
),
liability_decision_made AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Liability Decision Made' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Exposure Status column] IN ([Liability decision status value])
),
settlement_calculated AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Settlement Calculated' AS VARCHAR(100)) AS ActivityName,
p.[Payment Status Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Payment Status Timestamp column] >= [Start date parameter]
AND p.[Payment Status Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Pending approval payment status value]
),
payment_approved AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Approved' AS VARCHAR(100)) AS ActivityName,
p.[Approval Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment approval history table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Approval Timestamp column] >= [Start date parameter]
AND p.[Approval Timestamp column] < [End date parameter]
AND p.[Approval Status column] = [Approved payment status value]
),
payment_issued AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Issued' AS VARCHAR(100)) AS ActivityName,
p.[Issued Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment issuance table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Issued Timestamp column] >= [Start date parameter]
AND p.[Issued Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Issued payment status value]
),
claim_denied AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Denied' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] = [Denied status reason value]
),
claim_closed AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Closed' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] <> [Denied status reason value]
),
claim_reopened AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Reopened' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim status history table] previous_h
ON previous_h.[Claim ID column] = h.[Claim ID column]
AND previous_h.[Status Change Timestamp column] = (
SELECT MAX(prior_h.[Status Change Timestamp column])
FROM [Your claim status history table] prior_h
WHERE prior_h.[Claim ID column] = h.[Claim ID column]
AND prior_h.[Status Change Timestamp column] < h.[Status Change Timestamp column]
)
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND previous_h.[New Claim Status column] = [Closed claim status value]
AND h.[New Claim Status column] = [Open claim status value]
)
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_assigned
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM exposure_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM initial_reserve_set
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM investigation_started
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_requested
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_received
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM liability_decision_made
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM settlement_calculated
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_approved
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_issued
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_denied
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_closed
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_reopened
ORDER BY ClaimID, EventTime, ActivityName; ¿Listo para comenzar?
Utilice esta plantilla para preparar sus datos para el análisis y descubrir información útil sobre la gestión de sus siniestros. Comience a optimizar sus flujos de trabajo hoy mismo.
Agilice la gestión de siniestros y resuelva los casos más rápido
Elimine los casos pendientes, prevenga el fraude y alcance un 70 % de procesamiento directo.
No necesita tarjeta de crédito y puede configurarlo en solo unos minutos.