Su plantilla de datos de Gestión del Ciclo de Ingresos
Su plantilla de datos de Gestión del Ciclo de Ingresos
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía de Extracción
Atributos de Gestión del Ciclo de Ingresos
| Nombre | Descripción | ||
|---|---|---|---|
| Evento de Facturación BillingEvent | El identificador único para una sola prestación de servicio o producto que genera un cargo, sirviendo como el identificador principal del caso. | ||
| Descripción El Evento de Facturación es el identificador central que conecta todas las actividades dentro del ciclo de ingresos para un ítem facturable específico. Comienza cuando se presta un servicio y concluye cuando la cuenta está completamente liquidada o cerrada. En el análisis de Process Mining, este atributo es esencial para reconstruir el recorrido de extremo a extremo de cada cargo. Permite el seguimiento de actividades como la captura de cargos, el envío de reclamos, el registro de pagos y la gestión de denegaciones para eventos de facturación individuales, proporcionando una visión clara del flujo de trabajo del proceso y sus variaciones. Por qué es importante Este es el ID de Caso fundamental, crucial para vincular todos los pasos del proceso relacionados para analizar el ciclo de vida completo de la generación y cobranza de ingresos para cada servicio. Dónde obtener Este es a menudo un identificador único para una cuenta hospitalaria (HAR) o una sesión de cargo específica en Epic Resolute. Consulte la documentación de Epic Resolute para tablas específicas como HAR o registros de Sesión de Cargo. Ejemplos BE10098765BE20012345BE30054321 | |||
| Nombre de la Actividad ActivityName | El nombre del evento o tarea específica realizada dentro del proceso de gestión del ciclo de ingresos. | ||
| Descripción Este atributo describe un solo paso en el ciclo de ingresos, como 'Charges Captured', 'Claim Submitted to Payer' o 'Payment Received'. Cada actividad representa un hito distinto en el proceso de facturación y cobro de un servicio. Analizar actividades es la base de Process Mining. Permite la visualización del mapa de procesos, la identificación de vías comunes, el descubrimiento de cuellos de botella entre los pasos y la medición de la conformidad con los procedimientos operativos estándar. Por qué es importante Define los pasos en el mapa de procesos, haciendo posible visualizar, analizar y optimizar el flujo de trabajo en el ciclo de ingresos. Dónde obtener Esto se deriva típicamente de registros de eventos, pistas de auditoría o registros de cambio de estado dentro de los módulos de facturación y reclamos de Epic Resolute. Ejemplos Cargos capturadosReclamación presentada al pagadorPago RecibidoCuenta cerrada | |||
| Timestamp del Evento EventTimestamp | La fecha y hora exactas en que ocurrió una actividad o evento específico. | ||
| Descripción La Marca de Tiempo del Evento (Event Timestamp) registra el momento en que tuvo lugar una actividad. Estos datos temporales son críticos para comprender la temporización y secuenciación de los eventos en el ciclo de ingresos. En el análisis, las timestamps se utilizan para calcular duraciones entre actividades, como el retraso en la captura de cargos o el tiempo de registro de pagos. Permiten el descubrimiento de cuellos de botella, la medición de los tiempos de ciclo y el análisis del rendimiento del proceso en diferentes períodos de tiempo. Las timestamps precisas son esenciales para casi todos los KPI y dashboards basados en el tiempo. Por qué es importante Este atributo es esencial para calcular todas las métricas basadas en el tiempo, incluidos los tiempos de ciclo y las duraciones, que son fundamentales para identificar retrasos e ineficiencias. Dónde obtener Se encuentra en tablas de registro de transacciones o eventos dentro de Epic Resolute, asociado con cada actividad registrada. Los campos a menudo se nombran con sufijos como Dt, DTTM o Time. Ejemplos 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Código de motivo de denegación DenialReasonCode | Un código estandarizado que indica el motivo por el cual un pagador denegó una reclamación presentada. | ||
| Descripción Cuando un pagador rechaza un reclamo, proporciona un código de razón que explica la denegación, como 'Non-Covered Service', 'Duplicate Claim' o 'Requires Additional Information'. Estos códigos a menudo se estandarizan como Códigos de Razón de Ajuste de Reclamo (CARCs). Este atributo es la piedra angular del dashboard 'Claim Denial Rates And Reasons'. Analizar la frecuencia de diferentes códigos de denegación ayuda a identificar las causas raíz de las denegaciones, como problemas de credenciales, errores de codificación o autorizaciones previas faltantes, lo que permite iniciativas de mejora dirigidas. Por qué es importante Explica directamente por qué se rechazan las reclamaciones, proporcionando conocimientos accionables necesarios para reducir las tasas de denegación, prevenir la pérdida de ingresos y acelerar los pagos. Dónde obtener Estos datos se encuentran en las transacciones de respuesta de reclamos (como un archivo ANSI 835) recibidas de los pagadores y almacenadas dentro del módulo de gestión de reclamos de Epic Resolute. Ejemplos CO-16: Reclamación/servicio carece de informaciónOA-18: Reclamación/servicio duplicadoPR-96: Cargo(s) no cubierto(s) | |||
| Departamento de Facturación BillingDepartment | El departamento o equipo funcional responsable del evento o actividad de facturación. | ||
| Descripción Este atributo indica la unidad organizacional, como 'Inpatient Billing', 'Outpatient Billing' o 'Denial Management Team', que está asociada con el evento de facturación o realizó una actividad específica. Esta dimensión es crucial para el dashboard 'Billing Department Performance Metrics', permitiendo comparaciones lado a lado de métricas clave como las tasas de denegación o los tiempos de captura de cargos. Ayuda a la gerencia a identificar departamentos de alto rendimiento, estandarizar las mejores prácticas y asignar recursos de manera efectiva. Por qué es importante Permite la evaluación comparativa del rendimiento entre diferentes departamentos, ayudando a identificar las mejores prácticas y las áreas que necesitan mejora o recursos adicionales. Dónde obtener Esta información podría estar vinculada al registro de usuario, la cuenta del paciente o la ubicación del servicio dentro de Epic Resolute. Ejemplos Facturación de CardiologíaGestión del Ciclo de Ingresos de RadiologíaOficina Central de Facturación | |||
| Razón de Ajuste AdjustmentReason | La razón de un ajuste manual o automatizado realizado en el saldo de la cuenta de un paciente. | ||
| Descripción Este atributo explica por qué se modificó el saldo de una cuenta fuera de un pago o cargo estándar. Las razones pueden incluir asignaciones contractuales con pagadores, cancelaciones de saldos pequeños o correcciones por errores de registro. Esto es esencial para el dashboard 'Account Adjustment Volume By Type'. Al analizar las razones de los ajustes, las organizaciones pueden identificar fuentes de fuga de ingresos, comprender el impacto de los contratos de los pagadores y detectar posibles ineficiencias o errores en el proceso de facturación. Por qué es importante Proporciona información sobre la fuga de ingresos y la precisión de la facturación al explicar por qué se modifican los saldos de las cuentas, ayudando a reducir las cancelaciones innecesarias. Dónde obtener Ubicado en los detalles de las transacciones para entradas de ajuste dentro del módulo de contabilidad de pacientes de Epic Resolute. Ejemplos Ajuste contractualCancelación de saldo pequeñoCorrección de cargo duplicado | |||
| Saldo pendiente OutstandingBalance | El monto restante de dinero adeudado por el pagador o paciente por el evento de facturación. | ||
| Descripción Este atributo representa el saldo actual de cuentas por cobrar para un evento de facturación específico en el momento de la actividad. Refleja el estado financiero del caso a lo largo de su ciclo de vida. El saldo pendiente es crítico para la elaboración de informes financieros y para el 'Reporte de Antigüedad de Saldo Pendiente'. Analizar este valor a lo largo del tiempo y por diferentes dimensiones, como pagador o departamento, ayuda a priorizar los esfuerzos de cobranza, gestionar el flujo de caja y evaluar el riesgo financiero. Por qué es importante Mide directamente el impacto financiero de los retrasos del proceso y es esencial para priorizar las cobranzas, gestionar el flujo de caja y comprender las cuentas por cobrar. Dónde obtener Este es un campo central en el registro de la cuenta del paciente o la cuenta hospitalaria (HAR) en Epic Resolute. Es un saldo corriente que se actualiza mediante transacciones financieras. Ejemplos 1500.00250.750.00 | |||
| Tipo de Servicio ServiceType | La categoría o tipo de servicio médico prestado. | ||
| Descripción Este atributo clasifica el servicio facturable, por ejemplo, como 'Radiología', 'Cirugía', 'Consulta' o 'Visita a sala de emergencias'. Proporciona contexto clínico a los datos financieros. Analizar el ciclo de ingresos por tipo de servicio puede descubrir variaciones de proceso específicas de ciertas áreas clínicas. Por ejemplo, los procedimientos quirúrgicos pueden tener requisitos de captura de cargos y autorización más complejos que una visita estándar a la consulta, lo que lleva a diferentes comportamientos y desafíos del proceso. Por qué es importante Proporciona contexto clínico a los datos financieros, permitiendo el análisis de cómo los diferentes tipos de servicios médicos impactan el proceso del ciclo de ingresos y su eficiencia. Dónde obtener Derivado del catálogo maestro de descripción de cargos (CDM), línea de servicio o departamento asociado con la transacción de cargos en Epic. Ejemplos Cirugía para pacientes internosRadiología ambulatoriaServicios de Emergencia | |||
| Usuario Responsable ResponsibleUser | El identificador del usuario o empleado que realizó la actividad. | ||
| Descripción Este atributo captura el ID de usuario, nombre o número de empleado de la persona responsable de completar una tarea específica en el ciclo de ingresos. Esto podría ser el clínico que ingresó los cargos, el facturador que envió un reclamo o el cobrador que hizo seguimiento a una denegación. El análisis por usuario ayuda a identificar a los de mejor rendimiento, precisar las necesidades de capacitación y comprender la distribución de la carga de trabajo. Es clave para la gestión del rendimiento y para investigar desviaciones de procesos asociadas con individuos o roles específicos. Por qué es importante Permite el análisis de rendimiento por individuo o rol, ayudando a identificar oportunidades de capacitación, desequilibrios en la carga de trabajo y cuellos de botella relacionados con los recursos. Dónde obtener Típicamente se encuentra en los registros de auditoría o transacciones dentro de Epic Resolute, a menudo vinculado a una tabla de datos maestros de usuario (p. ej., registro EMP). Ejemplos j.doebsmith123User7890 | |||
| Automatizado IsAutomated | Un indicador booleano que señala si la actividad fue realizada por un sistema o un proceso automatizado. | ||
| Descripción Este indicador distingue entre tareas ejecutadas automáticamente por el sistema, como la generación automatizada de reclamos o las verificaciones de elegibilidad, y aquellas realizadas manualmente por un usuario. Analizar este atributo ayuda a comprender el nivel de automatización en el proceso. Puede utilizarse para comparar la eficiencia y las tasas de error de las actividades automatizadas frente a las manuales, identificar oportunidades para una mayor automatización y monitorear el rendimiento de los bots o reglas del sistema existentes. Por qué es importante Distingue entre actividades impulsadas por el sistema y por humanos, lo cual es clave para evaluar el impacto de la automatización e identificar nuevas oportunidades de automatización. Dónde obtener Esto a menudo se deriva verificando si el 'ResponsibleUser' de una actividad es una cuenta de sistema o de servicio, o marcando nombres de actividades específicas que se sabe que están automatizadas. Ejemplos truefalse | |||
| Claim ID ClaimId | El identificador único asignado a un reclamo de seguro enviado a un pagador. | ||
| Descripción Este atributo es el ID específico para el formulario de reclamo (p. ej., un CMS-1500 o UB-04) enviado a un pagador. Un solo evento de facturación podría involucrar múltiples reclamos si los servicios son refacturados o apelados. El seguimiento por Claim ID es útil para un análisis detallado de los subprocesos de envío de reclamos y gestión de denegaciones. Ayuda a distinguir las actividades relacionadas con el reclamo inicial de aquellas relacionadas con un reclamo posterior y reenviado por el mismo servicio. Por qué es importante Proporciona un identificador granular para rastrear el ciclo de vida de cada envío de reclamo específico, lo cual es crucial para analizar reenvíos y apelaciones. Dónde obtener Generado por el módulo de gestión de reclamaciones de Epic Resolute cuando se crea una reclamación. Se almacena en las tablas de datos de reclamaciones. Ejemplos CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Fecha de Vencimiento de Pago PaymentDueDate | La fecha en la que se espera el pago por el servicio facturado. | ||
| Descripción Este atributo especifica la fecha límite de pago, según se indica en la factura o según lo determinado por los contratos de los pagadores. Sirve como un punto de referencia para medir los pagos oportunos. La fecha de vencimiento del pago es esencial para crear el 'Reporte de Antigüedad de Saldo Pendiente'. Al comparar la fecha actual con la fecha de vencimiento de los saldos abiertos, las cuentas por cobrar pueden categorizarse en rangos de antigüedad (p. ej., 0-30 días, 31-60 días de atraso), lo que ayuda a priorizar los esfuerzos de cobranza en las cuentas más atrasadas. Por qué es importante Sirve como base para el análisis de antigüedad de cuentas por cobrar, lo cual es crítico para priorizar las cobranzas y gestionar el riesgo financiero de las facturas impagas. Dónde obtener Esta fecha a menudo se calcula en función de la fecha de la factura y los términos de pago almacenados en el contrato del pagador o la información de la cuenta del paciente dentro de Epic. Ejemplos 2023-05-302023-06-152023-07-01 | |||
| Hora Fin del Evento EventEndTime | La timestamp que indica cuándo se completó una actividad, útil para calcular la duración de la actividad. | ||
| Descripción Este atributo registra el tiempo de finalización de una actividad. Si bien muchas actividades son eventos instantáneos donde StartTime es igual a EndTime, algunas tareas tienen una duración medible, como una llamada de seguimiento de denegación. Cuando está disponible, EndTime permite el cálculo directo del tiempo de procesamiento de la actividad ('EndTime' - 'StartTime'). Esto es más preciso que inferir la duración a partir del tiempo de inicio de la siguiente actividad, ya que considera el tiempo de inactividad entre los pasos. Es un componente clave para calcular el atributo 'ProcessingTime'. Por qué es importante Permite el cálculo preciso de cuánto tiempo tarda cada actividad en completarse, lo cual es crucial para identificar tareas ineficientes y medir la productividad de los recursos. Dónde obtener Esto puede estar disponible en algunos módulos de Epic Resolute que rastrean el inicio y el final de las tareas, como colas de trabajo o registros de gestión de actividad. A menudo, no se rastrea explícitamente. Ejemplos 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| ID de Paciente PatientId | El identificador único del paciente que recibe el servicio. | ||
| Descripción Este atributo es el Número de Expediente Médico (MRN) u otro identificador único para el paciente. Vincula el evento de facturación financiera a un individuo específico. Si bien no se usa típicamente como una dimensión de análisis principal para proteger la privacidad del paciente, es esencial para la validación de datos y puede usarse para agregar todos los eventos de facturación para un solo paciente y comprender su recorrido financiero general. También es crucial para cualquier posible integración con datos de procesos clínicos. Por qué es importante Vincula los datos financieros a un paciente específico, permitiendo la validación de datos y el potencial para un análisis más amplio de toda la trayectoria de un paciente, aunque debe manejarse con cuidado debido a preocupaciones de privacidad. Dónde obtener Un identificador fundamental que se encuentra en todo Epic, vinculado a los registros de registro y cuenta del paciente. Ejemplos MRN-1234567MRN-8765432MRN-5551234 | |||
| Monto Ajustado AdjustedAmount | El valor monetario de una transacción de ajuste. | ||
| Descripción Este campo registra el monto específico en dólares de un ajuste de cuenta. Puede ser un valor positivo o negativo, representando un crédito o débito al saldo de la cuenta. Este monto es la métrica principal para el dashboard 'Account Adjustment Volume By Type'. Sumar este valor por razón de ajuste proporciona una imagen clara del impacto financiero de los diferentes tipos de ajustes, como cuánto ingreso se cancela debido a obligaciones contractuales versus cuánto se pierde por errores corregibles. Por qué es importante Cuantifica el impacto financiero de los ajustes de cuenta, haciendo posible medir la fuga de ingresos y el costo de las imprecisiones de facturación. Dónde obtener Ubicado en las tablas de detalles de transacciones financieras en Epic Resolute, asociado con transacciones de tipo ajuste. Ejemplos -1250.45-50.0025.10 | |||
| Nombre del Pagador PayerName | El nombre de la compañía de seguros, entidad gubernamental u otra parte responsable del pago. | ||
| Descripción Este atributo identifica al pagador principal asociado con el evento de facturación, como 'Blue Cross Blue Shield', 'Medicare' o 'Aetna'. En casos de autopago, puede indicar al paciente. Segmentar el proceso por pagador es una potente técnica de análisis. Puede revelar que ciertos pagadores tienen tasas de denegación más altas, ciclos de pago más largos o requisitos más complejos. Esta información permite adaptar las estrategias de facturación a pagadores específicos para mejorar la eficiencia y la velocidad de pago. Por qué es importante Permite el análisis de rendimiento por pagador, revelando qué pagadores tienen altas tasas de denegación o ciclos de pago lentos, lo que permite estrategias de seguimiento dirigidas. Dónde obtener Esta información forma parte de los detalles de cobertura del paciente, vinculada a la cuenta hospitalaria (HAR) en Epic Resolute. Ejemplos Medicare Part BUnitedHealthcareAetna PPO | |||
| Source System SourceSystem | El sistema de información del que se originan los datos. | ||
| Descripción Este atributo identifica el sistema fuente del registro, que para este contexto es Epic Resolute. En entornos con múltiples sistemas integrados, este campo ayuda a diferenciar los orígenes de los datos. Si bien puede parecer redundante en una vista de un solo sistema, es una buena práctica para la gobernanza de datos y la escalabilidad. Asegura claridad si los datos de otros sistemas, como una plataforma de agencia de cobranza separada, se integran más tarde. Por qué es importante Proporciona linaje y contexto de datos cruciales, asegurando claridad sobre el origen de los datos, lo cual es vital para la gobernanza de datos y la resolución de problemas. Dónde obtener Este es típicamente un valor estático añadido durante el proceso de extracción y transformación de datos para etiquetar el origen del dataset. Ejemplos Epic ResoluteEpicResolute_V2023 | |||
| Tiempo de Procesamiento ProcessingTime | La duración calculada del tiempo dedicado a trabajar activamente en una actividad. | ||
| Descripción El tiempo de procesamiento, también conocido como tiempo de manejo, mide la duración de una actividad desde su inicio hasta su fin. Representa el tiempo que un recurso estuvo activamente involucrado en la tarea. Esta métrica se calcula como la diferencia entre 'EventEndTime' y 'EventTimestamp'. Analizar el tiempo de procesamiento ayuda a identificar qué tareas específicas consumen más tiempo, permitiendo esfuerzos concentrados en la optimización y mejora de la eficiencia. Es una medida fundamental de la productividad de los recursos. Por qué es importante Mide la duración real del trabajo de las actividades, ayudando a identificar tareas que consumen mucho tiempo y a evaluar la eficiencia de los recursos. Dónde obtener Este no es un campo en el sistema fuente. Se calcula durante la transformación de datos usando la fórmula: EventEndTime - EventTimestamp. Ejemplos 900605120 | |||
| Tiempo total del ciclo de ingresos TotalRevenueCycleTime | La duración total calculada desde el primer evento de servicio hasta el pago final o el cierre de la cuenta. | ||
| Descripción Este es un KPI a nivel de caso que mide la duración de extremo a extremo del ciclo de ingresos para un único evento de facturación. Típicamente se calcula como la diferencia de tiempo entre la actividad 'Service Rendered' y la actividad final 'Payment Received' o 'Account Closed'. Esta métrica de alto nivel proporciona una vista holística de la eficiencia general del proceso de Gestión del Ciclo de Ingresos. El seguimiento de este KPI a lo largo del tiempo ayuda a medir el impacto de las iniciativas de mejora de procesos y proporciona un indicador clave de la velocidad de conversión de efectivo. Por qué es importante Proporciona una vista de alto nivel y de extremo a extremo de la eficiencia del proceso, midiendo directamente cuánto tiempo se tarda en convertir un servicio en efectivo. Dónde obtener Esta es una métrica calculada dentro de la herramienta de Process Mining filtrando por los primeros y últimos eventos de cada caso y encontrando la diferencia de tiempo. Ejemplos 259200038880005184000 | |||
| Última actualización de datos LastDataUpdate | El `timestamp` que indica cuándo los `datos` de este `evento` fueron actualizados o extraídos por última vez del sistema de origen. | ||
| Descripción Este atributo muestra la frescura de los datos. Indica la última vez que el registro fue extraído de Epic Resolute al conjunto de datos de Process Mining. Esto es importante para comprender la puntualidad del análisis y para fines de validación de datos. Ayuda a los usuarios a saber si están viendo la información más actual disponible y es crítico para gestionar los ciclos de actualización de datos. Por qué es importante Garantiza que los usuarios comprendan la actualidad de los datos que están analizando, lo cual es crítico para tomar decisiones de negocio precisas y actualizadas. Dónde obtener Esta timestamp es añadida por el proceso ETL (Extract, Transform, Load) durante la ingesta de datos. Ejemplos 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
Actividades de Gestión del Ciclo de Ingresos
| Actividad | Descripción | ||
|---|---|---|---|
| Cargos capturados | Representa el registro formal de los cargos facturables por los servicios prestados. En Epic, esta es típicamente una transacción explícita registrada en la cuenta del paciente, a menudo generada automáticamente a partir de acciones clínicas o ingresada manualmente. | ||
| Por qué es importante Este es un primer hito crítico. Medir la velocidad y la precisión de la captura de cargos ayuda a acelerar el proceso de facturación y a garantizar que todos los servicios prestados se facturen. Dónde obtener Registrado explícitamente en los registros de transacciones de Resolute. Cada cargo es una entrada discreta con una fecha de contabilización, fecha de servicio y monto, a menudo se encuentra en tablas como Capturar Capture las transacciones de contabilización de cargos del registro de transacciones financieras del sistema. Tipo de evento explicit | |||
| Cuenta cerrada | Esta es la actividad final, que significa que el saldo pendiente del evento de facturación ha llegado a cero y no hay más actividades pendientes. Esto puede deberse a un pago completo, ajustes o una cancelación. | ||
| Por qué es importante Este evento marca la finalización exitosa del ciclo de ingresos para un evento de facturación. La duración de extremo a extremo desde el servicio hasta el cierre es un KPI crítico para la eficiencia general del proceso. Dónde obtener Este es típicamente un evento inferido. Se determina identificando el punto en el tiempo en que el saldo de la cuenta para el evento de facturación se convierte en cero y permanece en cero. Capturar Inferido calculando un total acumulado del saldo de la cuenta e identificando el timestamp de la última transacción que dejó el saldo en cero. Tipo de evento inferred | |||
| Pago contabilizado en la cuenta | Este es el evento donde un pago recibido se aplica o asigna a cargos específicos en la cuenta del paciente. Esta acción reduce el saldo pendiente del evento de facturación. | ||
| Por qué es importante La contabilización eficiente de pagos es crucial para mantener saldos de cuenta precisos y cerrar eventos de facturación. Permite la identificación correcta de los saldos restantes para la facturación secundaria o las cobranzas. Dónde obtener Esta es una transacción explícita en Resolute. El registro de pago vincula una transacción de pago a una o más transacciones de cargo, lo cual se registra en las tablas de detalles de transacciones. Capturar Capture el registro de transacciones que aplica un pago a un cargo, identificable por tipos de transacción específicos. Tipo de evento explicit | |||
| Pago Recibido | Representa la recepción de pago de un pagador o paciente. Este evento es típicamente registrado cuando se carga un aviso de remesa electrónico (ERA) o se introduce un cheque manual en el sistema. | ||
| Por qué es importante Esta actividad es un hito importante que indica que los ingresos están llegando. El tiempo entre el envío del reclamo y la recepción del pago es una medida clave del rendimiento de las cuentas por cobrar. Dónde obtener Registrado explícitamente como una transacción de pago en Resolute. Estas transacciones se registran con una fecha, origen y monto, a menudo antes de que se contabilicen completamente en cargos individuales. Capturar Capture las transacciones de pago del registro de transacciones financieras, a menudo identificadas por tipos de transacción específicos. Tipo de evento explicit | |||
| Reclamación denegada por pagador | Representa la recepción de una notificación del pagador de que el reclamo ha sido denegado. Esto se captura cuando Epic procesa un aviso de remesa electrónico (archivo 835) o cuando un usuario registra manualmente una denegación. | ||
| Por qué es importante Esta actividad inicia un ciclo crítico de retrabajo. Analizar las razones y volúmenes de denegación es esencial para identificar las causas raíz, mejorar las tasas de pago en el primer intento y reducir los retrasos en la cobranza. Dónde obtener Registrado explícitamente como una transacción o actualización de estado en la reclamación. La información de denegación, incluidos los códigos de motivo, se recibe típicamente de forma electrónica y se contabiliza en la cuenta. Capturar Filtre por tipos de transacción específicos o actualizaciones de estado de reclamación que indican una denegación. Tipo de evento explicit | |||
| Reclamación presentada al pagador | Esto marca el evento en el que el reclamo se envía oficialmente al pagador del seguro para su adjudicación. En Epic, este es un evento rastreado, registrado cuando el archivo de reclamo electrónico se transmite a la cámara de compensación o al pagador. | ||
| Por qué es importante Este hito es crucial ya que inicia el plazo de pago del pagador. Analizar esto ayuda a medir la eficiencia del proceso de transmisión de reclamos y apoya el KPI de Tiempo de Entrega de Factura al Pagador. Dónde obtener Este es un evento explícito registrado en Resolute. El registro del reclamo tendrá un estado de envío y una timestamp que indica cuándo fue enviado. Capturar Capture el timestamp asociado con el cambio de estado de la reclamación a 'Enviada' o 'Transmitida'. Tipo de evento explicit | |||
| Servicio Prestado | Esta actividad marca el punto en que se presta un servicio clínico al paciente, lo que inicia el evento de facturación. Esto a menudo se captura del EHR de Epic (EpicCare) cuando un clínico aprueba una visita o procedimiento. | ||
| Por qué es importante Este es el evento de inicio principal para el ciclo de ingresos. Analizar el tiempo desde este punto hasta la captura de cargos es crítico para identificar retrasos en el inicio de la facturación y posibles fugas de ingresos. Dónde obtener Este evento se infiere típicamente de las timestamps de servicio o visita en los módulos clínicos que están vinculados a la cuenta de facturación. La fecha del servicio en la transacción de cargo es el punto clave de los datos. Capturar Inferido de la fecha de servicio asociada con la primera transacción de cargo para el evento de facturación. Tipo de evento inferred | |||
| Ajuste de cuenta realizado | Esta actividad representa una transacción de no pago que altera el saldo de la cuenta, como un ajuste contractual, una cancelación de saldo pequeño o un descuento por buena voluntad. Esto se registra como un tipo de transacción específico. | ||
| Por qué es importante Analizar los ajustes es clave para identificar la fuga de ingresos. Los altos volúmenes de ciertos tipos de ajuste pueden indicar problemas con los programas de tarifas, la contratación o las políticas internas. Dónde obtener Registrado explícitamente como transacciones de ajuste en los registros financieros de Resolute. Cada ajuste tendrá un tipo o código de motivo específico asociado. Capturar Filtre por tipos de transacción que corresponden a ajustes financieros o cancelaciones. Tipo de evento explicit | |||
| Reclamación generada | Esta actividad significa la creación por parte del sistema de un reclamo o factura formal basado en los cargos capturados. Es un paso preparatorio antes de que el reclamo sea enviado al pagador o al paciente. | ||
| Por qué es importante El seguimiento de la generación de reclamos ayuda a aislar los retrasos entre la captura de cargos y su preparación para el envío. Es un paso interno clave que puede impactar la puntualidad general de la facturación. Dónde obtener Esto se registra típicamente cuando se ejecuta un trabajo por lotes de generación de facturación o reclamos. El sistema registrará una timestamp cuando se cree el archivo de reclamo (como un archivo 837) para una cuenta determinada. Capturar Identifique entradas de registro o cambios de estado que indican que la reclamación ha sido compilada y está lista para su presentación. Tipo de evento explicit | |||
| Reclamación reenviada | Este evento ocurre después de que un reclamo denegado ha sido corregido y se envía de vuelta al pagador. Este es un evento de envío distinto que está vinculado al reclamo original. | ||
| Por qué es importante Esta es una parte clave del ciclo de retrabajo. Medir el tiempo de reenvío y la tasa de éxito de los reclamos reenviados es vital para comprender la efectividad del proceso de resolución de denegaciones. Dónde obtener Este es un evento explícito similar al envío inicial, pero a menudo marcado como un reenvío. El registro del reclamo mostrará una nueva timestamp de envío y puede incluir un código de reenvío. Capturar Capture el timestamp para una presentación de reclamación marcada como corrección o reenvío. Tipo de evento explicit | |||
| Saldo enviado a cobranzas | Esto marca el punto en que un saldo de cuenta impago se transfiere a un proceso de cobranza interno o externo. Este es a menudo un cambio de estado explícito en la cuenta o evento de facturación. | ||
| Por qué es importante Esta actividad inicia la etapa final de recuperación de saldos impagos. Rastrear la tasa de éxito y el tiempo de ciclo del proceso de cobranzas es vital para minimizar la deuda incobrable. Dónde obtener Este es típicamente un evento explícito. Epic tiene funciones para transferir cuentas a agencias de cobranza, lo que crea una entrada de registro o un cambio de estado en la cuenta. Capturar Identifique el cambio de estado o la transacción que indica que una cuenta ha sido colocada con una agencia de cobranza. Tipo de evento explicit | |||
| Seguimiento de denegación iniciado | Esta actividad marca el inicio del proceso interno para revisar y resolver un reclamo denegado. A menudo se captura cuando un usuario se apropia del reclamo denegado en una workqueue o cambia su estado. | ||
| Por qué es importante El seguimiento de esto ayuda a medir la capacidad de respuesta del equipo de gestión de denegaciones. Los retrasos entre una denegación y el inicio del seguimiento pueden extender el ciclo de ingresos innecesariamente. Dónde obtener Esto se infiere típicamente de los cambios en el estado o el historial de asignación del reclamo dentro de las workqueues de Epic. Por ejemplo, el estado del reclamo podría cambiar de 'Denied' a 'In Review'. Capturar Infrar de un cambio de estado de reclamación o de una entrada en el registro de auditoría que muestra que un usuario ha comenzado a trabajar en la denegación. Tipo de evento inferred | |||
Guías de Extracción
Pasos
- Establecer Conexión a la Base de Datos: Obtenga credenciales de solo lectura para la base de datos de Epic Clarity. Utilice un cliente SQL estándar, como DBeaver o Microsoft SQL Server Management Studio, para conectarse al servidor de la base de datos.
- Identificar Tablas Principales: Las tablas principales para esta extracción incluyen
HSP_ACCOUNTpara información de casos,HSP_TRANSACTIONSpara eventos financieros,CLP_CLAIM_INFOpara el estado de las reclamaciones yF_ARHB_TX_SET_POST_HXpara detalles de contabilización de pagos. También unirá archivos maestros comoCLARITY_EMPpara detalles de usuarios. - Definir el Alcance: Antes de escribir la consulta, determine el alcance de su análisis. Defina un rango de fechas específico, típicamente de 3 a 6 meses, e identifique cualquier área de servicio hospitalario específica (
SERV_AREA_ID) o clases de cuentas que desee incluir o excluir. - Desarrollar la Consulta SQL: Construya una consulta SQL utilizando una Common Table Expression (CTE) para seleccionar primero el conjunto de valores de
HSP_ACCOUNT_IDque caen dentro de su alcance definido. Esto servirá como la población base de eventos de facturación. - Unir Consultas de Actividades Individuales: Para cada una de las 12 actividades requeridas, escriba una declaración
SELECTseparada que recupere datos de las tablas relevantes. Vuelva a unirse a su CTE inicial para asegurarse de que solo analiza las cuentas deseadas. - Combinar Consultas con UNION ALL: Utilice el operador
UNION ALLpara combinar los resultados de todas las consultas de actividades individuales en un único y cohesivo registro de eventos. Esto apila las filas de cada consulta verticalmente. - Mapear a Esquema Estándar: En cada declaración
SELECT, asigne un alias a las columnas para que coincidan con el esquema requerido de ProcessMind:BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, etc. UtiliceNULLpara atributos que no sean aplicables a una actividad específica. - Ejecutar y Refinar la Consulta: Ejecute la consulta completa contra la base de datos de Clarity. Debido al tamaño de las tablas, esto puede llevar una cantidad significativa de tiempo. Si el rendimiento es un problema, restrinja aún más el rango de fechas o agregue filtros más específicos en la CTE inicial.
- Revisar la Salida: Una vez que la consulta se complete, inspeccione las primeras cientos de filas de la salida. Verifique que todas las columnas estén presentes, que los
timestampsestén en un formato consistente y que los diferentes valores deActivityNameaparezcan como se esperaba. - Exportar a CSV: Exporte todo el conjunto de resultados de su cliente SQL a un archivo CSV. Asegúrese de que el archivo utilice codificación UTF-8 e incluya una fila de encabezado con los nombres de columna correctos.
- Preparar para la Carga: Antes de cargar a ProcessMind, abra el archivo CSV para confirmar que no hay errores de formato. Verifique que el formato del
timestampsea consistente, por ejemplo,YYYY-MM-DD HH:MI:SS. El archivo ahora está listo para la ingesta.
Configuración
- Conexión a la base de datos: Se requiere una cuenta de usuario de solo lectura con acceso a la base de datos de Epic Clarity.
- Parámetros de rango de fechas: La consulta proporcionada utiliza las variables
@StartDatey@EndDate. Estas deben configurarse para definir el período de análisis. Se recomienda un rango de 3 a 6 meses para equilibrar el volumen de datos y el rendimiento. - Mapeo de tablas y columnas: La consulta asume nombres estándar para tablas y columnas de Clarity. La configuración o versión específica de Epic de su organización puede tener variaciones. Es posible que deba ajustar los nombres de las tablas, los nombres de las columnas o las condiciones de unión según sea necesario.
- Códigos de transacción y estado: La consulta incluye marcadores de posición como
[Your Denial Tx Type]y[Your Collections Status Code]. Debe consultar a los administradores de su sistema Epic o revisar los archivos maestros relevantes, comoZC_TX_TYPEoZC_ACCOUNT_STATUS, para encontrar los códigos correctos para su instancia. - Filtrado: Para un mejor rendimiento y un análisis más enfocado, agregue filtros a la CTE
BaseAccountsinicial. Los filtros comunes incluyenSERV_AREA_IDpara limitar por área de servicio hospitalario oACCOUNT_CLASS_Cpara enfocarse en la facturación de pacientes internos o externos.
a Consulta de ejemplo sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp; Pasos
- Establecer Conexión a la Base de Datos: Obtenga credenciales de solo lectura para la base de datos de Epic Clarity. Utilice un cliente SQL estándar, como DBeaver o Microsoft SQL Server Management Studio, para conectarse al servidor de la base de datos.
- Identificar Tablas Principales: Las tablas principales para esta extracción incluyen
HSP_ACCOUNTpara información de casos,HSP_TRANSACTIONSpara eventos financieros,CLP_CLAIM_INFOpara el estado de las reclamaciones yF_ARHB_TX_SET_POST_HXpara detalles de contabilización de pagos. También unirá archivos maestros comoCLARITY_EMPpara detalles de usuarios. - Definir el Alcance: Antes de escribir la consulta, determine el alcance de su análisis. Defina un rango de fechas específico, típicamente de 3 a 6 meses, e identifique cualquier área de servicio hospitalario específica (
SERV_AREA_ID) o clases de cuentas que desee incluir o excluir. - Desarrollar la Consulta SQL: Construya una consulta SQL utilizando una Common Table Expression (CTE) para seleccionar primero el conjunto de valores de
HSP_ACCOUNT_IDque caen dentro de su alcance definido. Esto servirá como la población base de eventos de facturación. - Unir Consultas de Actividades Individuales: Para cada una de las 12 actividades requeridas, escriba una declaración
SELECTseparada que recupere datos de las tablas relevantes. Vuelva a unirse a su CTE inicial para asegurarse de que solo analiza las cuentas deseadas. - Combinar Consultas con UNION ALL: Utilice el operador
UNION ALLpara combinar los resultados de todas las consultas de actividades individuales en un único y cohesivo registro de eventos. Esto apila las filas de cada consulta verticalmente. - Mapear a Esquema Estándar: En cada declaración
SELECT, asigne un alias a las columnas para que coincidan con el esquema requerido de ProcessMind:BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, etc. UtiliceNULLpara atributos que no sean aplicables a una actividad específica. - Ejecutar y Refinar la Consulta: Ejecute la consulta completa contra la base de datos de Clarity. Debido al tamaño de las tablas, esto puede llevar una cantidad significativa de tiempo. Si el rendimiento es un problema, restrinja aún más el rango de fechas o agregue filtros más específicos en la CTE inicial.
- Revisar la Salida: Una vez que la consulta se complete, inspeccione las primeras cientos de filas de la salida. Verifique que todas las columnas estén presentes, que los
timestampsestén en un formato consistente y que los diferentes valores deActivityNameaparezcan como se esperaba. - Exportar a CSV: Exporte todo el conjunto de resultados de su cliente SQL a un archivo CSV. Asegúrese de que el archivo utilice codificación UTF-8 e incluya una fila de encabezado con los nombres de columna correctos.
- Preparar para la Carga: Antes de cargar a ProcessMind, abra el archivo CSV para confirmar que no hay errores de formato. Verifique que el formato del
timestampsea consistente, por ejemplo,YYYY-MM-DD HH:MI:SS. El archivo ahora está listo para la ingesta.
Configuración
- Conexión a la base de datos: Se requiere una cuenta de usuario de solo lectura con acceso a la base de datos de Epic Clarity.
- Parámetros de rango de fechas: La consulta proporcionada utiliza las variables
@StartDatey@EndDate. Estas deben configurarse para definir el período de análisis. Se recomienda un rango de 3 a 6 meses para equilibrar el volumen de datos y el rendimiento. - Mapeo de tablas y columnas: La consulta asume nombres estándar para tablas y columnas de Clarity. La configuración o versión específica de Epic de su organización puede tener variaciones. Es posible que deba ajustar los nombres de las tablas, los nombres de las columnas o las condiciones de unión según sea necesario.
- Códigos de transacción y estado: La consulta incluye marcadores de posición como
[Your Denial Tx Type]y[Your Collections Status Code]. Debe consultar a los administradores de su sistema Epic o revisar los archivos maestros relevantes, comoZC_TX_TYPEoZC_ACCOUNT_STATUS, para encontrar los códigos correctos para su instancia. - Filtrado: Para un mejor rendimiento y un análisis más enfocado, agregue filtros a la CTE
BaseAccountsinicial. Los filtros comunes incluyenSERV_AREA_IDpara limitar por área de servicio hospitalario oACCOUNT_CLASS_Cpara enfocarse en la facturación de pacientes internos o externos.
a Consulta de ejemplo sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp;