Su Template de datos para la gestión del ciclo de ingresos
Su Template de datos para la gestión del ciclo de ingresos
- Atributos recomendados para recopilar
- Actividades clave que conviene seguir
- Guía de extracción
Atributos de la gestión del ciclo de ingresos
| Nombre | Descripción | ||
|---|---|---|---|
| Evento de facturación BillingEvent | Identificador único de una prestación de servicio o entrega de producto que genera un cargo y sirve como identificador principal del caso. | ||
| Descripción El evento de facturación es el identificador principal que conecta todas las actividades del ciclo de ingresos de un concepto facturable. Comienza cuando se presta un servicio y termina cuando la cuenta queda totalmente saldada o cerrada. En el análisis de Process Mining, este atributo es esencial para reconstruir el recorrido completo de cada cargo. Permite hacer un seguimiento de actividades como la captura de cargos, el envío de reclamaciones, el registro de pagos y la gestión de rechazos en cada evento de facturación, y ofrece una visión clara del flujo del proceso y sus variaciones. Por qué es importante Este es el ID del caso fundamental, necesario para vincular todos los pasos relacionados del proceso y analizar el ciclo completo de generación y cobro de ingresos de cada servicio. Dónde obtenerlo A menudo es un identificador único de una cuenta hospitalaria (HAR) o de una sesión de cargos específica en Epic Resolute. Consulte la documentación de Epic Resolute para obtener información sobre tablas específicas, como los registros HAR o de sesiones de cargos. Ejemplos BE10098765BE20012345BE30054321 | |||
| Marca de tiempo del evento EventTimestamp | Fecha y hora exactas en que se produjo una actividad o un evento específicos. | ||
| Descripción La marca de tiempo del evento registra el momento en que se realizó una actividad. Estos datos temporales son fundamentales para comprender el momento y la secuencia de los eventos del ciclo de ingresos. En el análisis, las marcas de tiempo se utilizan para calcular la duración entre actividades, como la demora en la captura de cargos o el tiempo de registro de pagos. Permiten detectar cuellos de botella, medir los tiempos de ciclo y analizar el rendimiento de los procesos en distintos periodos. Las marcas de tiempo 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, fundamentales para detectar demoras e ineficiencias. Dónde obtenerlo Se encuentra en las tablas de transacciones o registros de eventos de Epic Resolute y está asociado a cada actividad registrada. Los nombres de los campos suelen terminar en Dt, DTTM o Time. Ejemplos 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Nombre de la actividad ActivityName | Nombre del evento o la tarea específicos realizados durante el proceso de gestión del ciclo de ingresos. | ||
| Descripción Este atributo describe un paso del ciclo de ingresos, como 'Cargos capturados', 'Reclamación enviada al pagador' o 'Pago recibido'. Cada actividad representa un hito distinto del proceso de facturación y cobro de un servicio. El análisis de las actividades es la base de Process Mining. Permite visualizar el mapa del proceso, identificar las rutas habituales, detectar cuellos de botella entre pasos y medir la conformidad con los procedimientos operativos estándar. Por qué es importante Define los pasos del mapa del proceso y permite visualizar, analizar y optimizar el flujo de trabajo del ciclo de ingresos. Dónde obtenerlo Suele obtenerse de los registros de eventos, las pistas de auditoría o los registros de cambios de estado de los módulos de facturación y reclamaciones de Epic Resolute. Ejemplos Cargos capturadosReclamación enviada al pagadorPago recibidoCuenta cerrada | |||
| Código del motivo del rechazo DenialReasonCode | Código estandarizado que indica por qué un pagador rechazó una reclamación enviada. | ||
| Descripción Cuando un pagador rechaza una reclamación, proporciona un código que explica el motivo, como 'Servicio no cubierto', 'Reclamación duplicada' o 'Se requiere información adicional'. Estos códigos suelen estar estandarizados como códigos de motivo de ajuste de reclamaciones (CARC). Este atributo es la base del Dashboard 'Tasas y motivos de rechazo de reclamaciones'. Analizar la frecuencia de los distintos códigos de rechazo ayuda a identificar sus causas principales, como problemas de acreditación, errores de codificación o autorizaciones previas faltantes, y permite poner en marcha iniciativas de mejora específicas. Por qué es importante Explica directamente por qué se rechazan las reclamaciones y proporciona información útil para reducir las tasas de rechazo, prevenir pérdidas de ingresos y acelerar los pagos. Dónde obtenerlo Estos datos se encuentran en las transacciones de respuesta a reclamaciones, como los archivos ANSI 835, que envían los pagadores y se almacenan en el módulo de gestión de reclamaciones de Epic Resolute. Ejemplos CO-16: A la reclamación o al servicio le falta informaciónOA-18: Reclamación o servicio duplicadoPR-96: Cargo(s) no cubierto(s) | |||
| Departamento de facturación BillingDepartment | Departamento o equipo funcional responsable del evento de facturación o de la actividad. | ||
| Descripción Este atributo indica la unidad organizativa, como 'Facturación de hospitalización', 'Facturación ambulatoria' o 'Equipo de gestión de rechazos', asociada al evento de facturación o responsable de una actividad específica. Esta dimensión es fundamental para el Dashboard 'Métricas de rendimiento del departamento de facturación', que permite comparar lado a lado métricas clave, como las tasas de rechazo o los tiempos de captura de cargos. Ayuda a la dirección a identificar los departamentos con mejores resultados, estandarizar las buenas prácticas y asignar los recursos de forma eficaz. Por qué es importante Permite comparar el rendimiento de distintos departamentos e identificar buenas prácticas, áreas que necesitan mejoras y necesidades de recursos adicionales. Dónde obtenerlo Esta información puede estar vinculada al registro del usuario, a la cuenta del paciente o al lugar donde se prestó el servicio en Epic Resolute. Ejemplos Facturación de cardiologíaGestión del ciclo de ingresos de radiologíaOficina central de facturación | |||
| Motivo del ajuste AdjustmentReason | Motivo de un ajuste manual o automático del saldo de la cuenta de un paciente. | ||
| Descripción Este atributo explica por qué se modificó el saldo de una cuenta por un motivo distinto de un pago o un cargo estándar. Entre los motivos se incluyen los descuentos contractuales de los pagadores, la condonación de saldos pequeños o las correcciones de errores de registro. Es fundamental para el Dashboard 'Volumen de ajustes de cuenta por tipo'. Analizar los motivos de los ajustes permite identificar fuentes de pérdidas de ingresos, comprender el impacto de los contratos con los pagadores y detectar posibles ineficiencias o errores en el proceso de facturación. Por qué es importante Ayuda a comprender las pérdidas de ingresos y la precisión de la facturación al explicar por qué se modifican los saldos de las cuentas, y permite reducir las condonaciones innecesarias. Dónde obtenerlo Se encuentra en los detalles de las transacciones de ajuste del módulo de contabilidad de pacientes de Epic Resolute. Ejemplos Descuento contractualCondonación de saldo pequeñoCorrección de cargo duplicado | |||
| Saldo pendiente OutstandingBalance | Importe que el pagador o el paciente aún debe por el evento de facturación. | ||
| Descripción Este atributo representa el saldo actual de las cuentas por cobrar de un evento de facturación específico en el momento de la actividad. Refleja la situación financiera del caso durante todo su ciclo de vida. El saldo pendiente es fundamental para los informes financieros y para el 'Informe de antigüedad de saldos pendientes'. Analizar su evolución y desglosarlo por dimensiones, como el pagador o el departamento, ayuda a priorizar las gestiones de cobro, administrar el flujo de caja y evaluar el riesgo financiero. Por qué es importante Mide directamente el impacto financiero de las demoras del proceso y es esencial para priorizar los cobros, administrar el flujo de caja y comprender las cuentas por cobrar. Dónde obtenerlo Es un campo principal del registro de la cuenta del paciente o de la cuenta hospitalaria (HAR) en Epic Resolute. Es un saldo acumulado que se actualiza con las transacciones financieras. Ejemplos 1500.00250.750.00 | |||
| Tipo de servicio ServiceType | 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 urgencias». Aporta contexto clínico a los datos financieros. El análisis del ciclo de ingresos por tipo de servicio puede revelar variaciones del proceso propias de determinadas áreas clínicas. Por ejemplo, los procedimientos quirúrgicos pueden requerir una captura de cargos y autorizaciones más complejas que una consulta ambulatoria estándar, lo que da lugar a dinámicas y desafíos distintos. Por qué es importante Aporta contexto clínico a los datos financieros y permite analizar cómo afectan los distintos tipos de servicios médicos al proceso del ciclo de ingresos y a su eficiencia. Dónde obtenerlo Se obtiene del maestro de descripciones de cargos (CDM), la línea de servicio o el departamento asociado a la transacción del cargo en Epic. Ejemplos Cirugía con hospitalizaciónRadiología ambulatoriaServicios de urgencias | |||
| Usuario responsable ResponsibleUser | Identificador del usuario o empleado que realizó la actividad. | ||
| Descripción Este atributo registra el ID de usuario, el nombre o el número de empleado de la persona responsable de completar una tarea específica del ciclo de ingresos. Puede ser el profesional clínico que introdujo los cargos, la persona encargada de facturación que envió una reclamación o quien hizo el seguimiento de un rechazo. El análisis por usuario ayuda a identificar a quienes obtienen mejores resultados, detectar necesidades de formación y comprender cómo se distribuye la carga de trabajo. Es clave para gestionar el rendimiento e investigar desviaciones del proceso asociadas a personas o roles específicos. Por qué es importante Permite analizar el rendimiento por persona o rol y ayuda a identificar oportunidades de formación, desequilibrios en la carga de trabajo y cuellos de botella relacionados con los recursos. Dónde obtenerlo Suele encontrarse en las pistas de auditoría o los registros de transacciones de Epic Resolute y a menudo está vinculado a una tabla maestra de usuarios, como el registro EMP. Ejemplos j.doebsmith123User7890 | |||
| Es automatizada IsAutomated | Indicador booleano que señala si la actividad la realizó el sistema o un proceso automatizado. | ||
| Descripción Este indicador distingue las tareas que el sistema ejecuta automáticamente, como la generación de reclamaciones o las comprobaciones de elegibilidad, de las que realiza una persona usuaria. El análisis de este atributo ayuda a comprender el grado de automatización del proceso. Permite comparar la eficiencia y las tasas de error de las actividades automatizadas y manuales, identificar oportunidades para automatizar más tareas y supervisar el rendimiento de los bots o las reglas del sistema existentes. Por qué es importante Distingue las actividades realizadas por el sistema de las realizadas por personas. Esto es clave para evaluar el impacto de la automatización e identificar nuevas oportunidades para automatizar tareas. Dónde obtenerlo A menudo se determina comprobando si el «ResponsibleUser» de una actividad es una cuenta del sistema o de servicio, o marcando los nombres de actividades que se sabe que están automatizadas. Ejemplos truefalse | |||
| Fecha de vencimiento del pago PaymentDueDate | Fecha límite prevista para el pago del servicio facturado. | ||
| Descripción Este atributo indica la fecha límite de pago que figura en la factura o que establecen los contratos con los pagadores. Sirve como referencia para medir la puntualidad de los pagos. La fecha de vencimiento del pago es esencial para generar el «Informe de antigüedad de saldos pendientes». Al comparar la fecha actual con la fecha de vencimiento de los saldos abiertos, las cuentas por cobrar se pueden clasificar por antigüedad (por ejemplo, de 0 a 30 días o de 31 a 60 días de vencimiento). Esto ayuda a priorizar las gestiones de cobro de las cuentas más atrasadas. Por qué es importante Sirve de base para el análisis de antigüedad de las cuentas por cobrar, fundamental para priorizar los cobros y gestionar el riesgo financiero de las facturas impagadas. Dónde obtenerlo Esta fecha suele calcularse a partir de la fecha de la factura y las condiciones de pago almacenadas en el contrato con el pagador o en la información de la cuenta del paciente en Epic. Ejemplos 2023-05-302023-06-152023-07-01 | |||
| Hora de finalización del evento EventEndTime | Marca de tiempo que indica cuándo se completó una actividad y permite calcular su duración. | ||
| Descripción Este atributo registra la hora de finalización de una actividad. Muchas actividades son eventos instantáneos en los que StartTime y EndTime coinciden, pero algunas tareas tienen una duración medible, como una llamada de seguimiento por una denegación. Cuando está disponible, EndTime permite calcular directamente el tiempo de procesamiento de la actividad («EndTime» - «StartTime»). Este cálculo es más preciso que inferir la duración a partir de la hora de inicio de la actividad siguiente, ya que tiene en cuenta el tiempo de inactividad entre pasos. Es un componente clave para calcular el atributo «ProcessingTime». Por qué es importante Permite calcular con precisión cuánto tarda en completarse cada actividad, algo fundamental para identificar tareas ineficientes y medir la productividad de los recursos. Dónde obtenerlo Puede estar disponible en algunos módulos de Epic Resolute que registran el inicio y el fin de las tareas, como los registros de colas de trabajo o de gestión de actividades. A menudo, no se registra de forma explícita. Ejemplos 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| ID de la reclamación ClaimId | Identificador único asignado a una reclamación de seguro enviada a un pagador. | ||
| Descripción Este atributo es el ID específico del formulario de reclamación (por ejemplo, CMS-1500 o UB-04) enviado a un pagador. Un mismo evento de facturación puede incluir varias reclamaciones si se vuelve a facturar un servicio o se presenta una apelación. El seguimiento por ID de reclamación resulta útil para analizar en detalle los subprocesos de envío y gestión de denegaciones. Permite distinguir las actividades de la reclamación inicial de las correspondientes a una reclamación posterior, reenviada para el mismo servicio. Por qué es importante Proporciona un identificador detallado para seguir el ciclo de vida de cada reclamación enviada, algo esencial para analizar los reenvíos y las apelaciones. Dónde obtenerlo Lo genera el módulo de gestión de reclamaciones de Epic Resolute al crear una reclamación. Se almacena en las tablas de datos de reclamaciones. Ejemplos CLM-2023-98765CLAIM-0012345623189A4567 | |||
| ID del paciente PatientId | Identificador único del paciente que recibe el servicio. | ||
| Descripción Este atributo es el número de historia clínica (MRN) u otro identificador único del paciente. Vincula el evento de facturación financiera con una persona concreta. Aunque normalmente no se utiliza como dimensión principal de análisis para proteger la privacidad del paciente, es esencial para validar los datos y puede servir para agrupar todos los eventos de facturación de un paciente y comprender su recorrido financiero completo. También es fundamental para cualquier posible integración con datos de procesos clínicos. Por qué es importante Vincula los datos financieros con un paciente concreto, lo que permite validar los datos y, potencialmente, analizar el recorrido completo del paciente. Debe tratarse con cuidado para proteger la privacidad. Dónde obtenerlo Identificador fundamental que aparece en todo Epic y está vinculado a los registros de inscripción y de cuenta del paciente. Ejemplos MRN-1234567MRN-8765432MRN-5551234 | |||
| Importe del ajuste AdjustedAmount | Valor monetario de una transacción de ajuste. | ||
| Descripción Este campo registra el importe exacto en dólares de un ajuste de cuenta. Puede ser positivo o negativo y representar un abono o un cargo en el saldo de la cuenta. Este importe es la métrica principal del Dashboard «Volumen de ajustes de cuenta por tipo». Al sumar este valor por motivo del ajuste, se obtiene una visión clara del impacto financiero de cada tipo de ajuste, por ejemplo, cuánto ingreso se da de baja por obligaciones contractuales frente a cuánto se pierde por errores que podrían corregirse. Por qué es importante Cuantifica el impacto financiero de los ajustes de cuenta y permite medir las pérdidas de ingresos y el coste de las imprecisiones en la facturación. Dónde obtenerlo Se encuentra en las tablas de detalle de transacciones financieras de Epic Resolute y está asociado a transacciones de tipo ajuste. Ejemplos -1250.45-50.0025.10 | |||
| Nombre del pagador PayerName | Nombre de la aseguradora, la entidad gubernamental u otra parte responsable del pago. | ||
| Descripción Este atributo identifica al pagador principal asociado al evento de facturación, como 'Blue Cross Blue Shield', 'Medicare' o 'Aetna'. En los casos de pago directo, puede indicar al paciente. Segmentar el proceso por pagador es una técnica de análisis eficaz. Puede revelar que ciertos pagadores tienen tasas de rechazo 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 cada pagador para mejorar la eficiencia y agilizar los pagos. Por qué es importante Permite analizar el rendimiento por pagador, detectar cuáles tienen tasas de rechazo elevadas o ciclos de pago lentos y definir estrategias de seguimiento específicas. Dónde obtenerlo Esta información forma parte de los datos de cobertura del paciente y está vinculada a la cuenta hospitalaria (HAR) en Epic Resolute. Ejemplos Medicare Parte BUnitedHealthcareAetna PPO | |||
| Sistema de origen SourceSystem | Sistema de información del que proceden los datos. | ||
| Descripción Este atributo identifica el sistema de origen del registro, que en este caso es Epic Resolute. En entornos con varios sistemas integrados, este campo ayuda a distinguir la procedencia de los datos. Aunque pueda parecer redundante cuando se utiliza un solo sistema, es una buena práctica para la gobernanza de datos y la escalabilidad. Aporta claridad si más adelante se integran datos de otros sistemas, como una plataforma independiente de una agencia de cobro. Por qué es importante Proporciona información esencial sobre la procedencia y el contexto de los datos. Esto permite conocer su origen, algo fundamental para la gobernanza de datos y la resolución de problemas. Dónde obtenerlo Suele ser un valor estático que se añade durante la extracción y transformación de los datos para indicar el origen del conjunto de datos. Ejemplos Epic ResoluteEpicResolute_V2023 | |||
| Tiempo total del ciclo de ingresos TotalRevenueCycleTime | Duración total calculada desde el primer evento del servicio hasta el pago final o el cierre de la cuenta. | ||
| Descripción Este KPI a nivel de caso mide la duración integral del ciclo de ingresos de un evento de facturación. Por lo general, se calcula como la diferencia entre la actividad «Servicio prestado» y la actividad final «Pago recibido» o «Cuenta cerrada». Esta métrica de alto nivel ofrece una visión global de la eficiencia del proceso de gestión del ciclo de ingresos (RCM). El seguimiento de este KPI a lo largo del tiempo permite medir el impacto de las iniciativas de mejora de procesos y sirve como indicador clave de la velocidad de conversión en efectivo. Por qué es importante Ofrece una visión integral de la eficiencia del proceso y mide directamente cuánto se tarda en convertir un servicio en efectivo. Dónde obtenerlo Esta métrica se calcula en la herramienta de Process Mining: se filtran el primer y el último evento de cada caso y se obtiene la diferencia de tiempo. Ejemplos 259200038880005184000 | |||
| Última actualización de los datos LastDataUpdate | Marca de tiempo que indica cuándo se actualizaron o extrajeron por última vez los datos de este evento del sistema de origen. | ||
| Descripción Este atributo indica la actualidad de los datos y muestra cuándo se transfirió por última vez el registro de Epic Resolute al conjunto de datos de Process Mining. Es importante para conocer la vigencia del análisis y validar los datos. Ayuda a saber si se está consultando la información más reciente disponible y es fundamental para gestionar los ciclos de actualización de datos. Por qué es importante Permite saber si los datos analizados están actualizados, algo fundamental para tomar decisiones empresariales precisas y basadas en la información más reciente. Dónde obtenerlo El proceso ETL (extracción, transformación y carga) añade esta marca de tiempo durante la incorporación de los 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, suele ser una transacción explícita registrada en la cuenta del paciente, generada a menudo automáticamente a partir de acciones clínicas o introducida manualmente. | ||
| Por qué es importante Este es un primer hito fundamental. Medir la rapidez y la precisión de la captura de cargos ayuda a acelerar la facturación y a garantizar que se facturen todos los servicios prestados. Dónde obtenerlo Se registra explícitamente en los registros de transacciones de Resolute. Cada cargo es una entrada independiente con fecha de registro, fecha del servicio e importe. Suele encontrarse en tablas como ARPB_TRANSACTIONS. Capturar Capture las transacciones de registro de cargos del registro de transacciones financieras del sistema. Tipo de evento explicit | |||
| Cuenta cerrada | Esta es la actividad final. Indica que el saldo pendiente del evento de facturación ha llegado a cero y que no quedan actividades pendientes. Puede deberse al pago total, a ajustes o a una condonación. | ||
| Por qué es importante Este evento marca la finalización satisfactoria del ciclo de ingresos de un evento de facturación. La duración total desde la prestación del servicio hasta el cierre es un KPI fundamental para medir la eficiencia general del proceso. Dónde obtenerlo Este evento suele inferirse. Se determina identificando el momento en que el saldo de la cuenta del evento de facturación llega a cero y permanece en ese valor. Capturar Se infiere calculando el saldo acumulado de la cuenta e identificando la marca de tiempo de la última transacción que dejó el saldo en cero. Tipo de evento inferred | |||
| Pago recibido | Representa la recepción de un pago del pagador o del paciente. Este evento suele registrarse cuando se carga una explicación electrónica de pago (ERA) o se introduce un cheque manual en el sistema. | ||
| Por qué es importante Esta actividad es un hito importante que indica la entrada de ingresos. El tiempo transcurrido entre el envío de la reclamación y la recepción del pago es una medida clave del rendimiento de las cuentas por cobrar. Dónde obtenerlo Se registra explícitamente como una transacción de pago en Resolute. Estas transacciones incluyen una fecha, un origen y un importe, y suelen registrarse antes de aplicarse por completo a los cargos individuales. Capturar Capture las transacciones de pago del registro de transacciones financieras. Suelen identificarse por tipos de transacción específicos. Tipo de evento explicit | |||
| Pago registrado en la cuenta | Este evento se produce cuando un pago recibido se aplica o asigna a cargos específicos de la cuenta del paciente. Esta acción reduce el saldo pendiente del evento de facturación. | ||
| Por qué es importante Registrar los pagos de forma eficiente es fundamental para mantener saldos de cuenta precisos y cerrar los eventos de facturación. También permite identificar correctamente los saldos restantes para la facturación secundaria o el cobro. Dónde obtenerlo Esta es una transacción explícita en Resolute. El registro del pago vincula una transacción de pago con una o varias transacciones de cargos, y queda reflejado en las tablas de detalles de transacciones. Capturar Capture el registro de la transacción que aplica un pago a un cargo. Puede identificarlo por tipos de transacción específicos. Tipo de evento explicit | |||
| Reclamación enviada al pagador | Este evento marca el envío oficial de la reclamación a la aseguradora para que la evalúe. En Epic, se registra cuando el archivo electrónico de la reclamación se transmite a la cámara de compensación o al pagador. | ||
| Por qué es importante Este hito es fundamental porque inicia el plazo de pago del pagador. Analizarlo permite medir la eficiencia del proceso de transmisión de reclamaciones y contribuye al KPI Tiempo de envío de la factura al pagador. Dónde obtenerlo Este evento se registra explícitamente en Resolute. El registro de la reclamación incluye un estado de envío y una marca de tiempo que indica cuándo se envió. Capturar Capture la marca de tiempo asociada al cambio de estado de la reclamación a 'Enviada' o 'Transmitida'. Tipo de evento explicit | |||
| Reclamación rechazada por el pagador | Representa la recepción de una notificación del pagador que indica que la reclamación ha sido rechazada. Se registra cuando Epic procesa una explicación electrónica de pago (archivo 835) o cuando una persona registra manualmente el rechazo. | ||
| Por qué es importante Esta actividad inicia un ciclo de trabajo repetido fundamental. Analizar los motivos y el volumen de los rechazos es esencial para identificar las causas principales, mejorar la tasa de pago en el primer envío y reducir las demoras en los cobros. Dónde obtenerlo Se registra explícitamente como una transacción o una actualización del estado de la reclamación. La información del rechazo, incluidos los códigos de motivo, suele recibirse electrónicamente y registrarse en la cuenta. Capturar Filtre los tipos de transacción o las actualizaciones del estado de la reclamación que indiquen un rechazo. Tipo de evento explicit | |||
| Servicio prestado | Esta actividad marca el momento en que se presta un servicio clínico al paciente y se inicia el evento de facturación. A menudo se registra en Epic EHR (EpicCare) cuando un profesional clínico firma una consulta o un procedimiento. | ||
| Por qué es importante Este es el evento de inicio principal del ciclo de ingresos. Analizar el tiempo transcurrido desde este momento hasta la captura del cargo es fundamental para detectar demoras en el inicio de la facturación y posibles pérdidas de ingresos. Dónde obtenerlo Este evento suele inferirse a partir de las marcas de tiempo del servicio o de la consulta en los módulos clínicos vinculados a la cuenta de facturación. La fecha del servicio en la transacción del cargo es el dato clave. Capturar Se infiere a partir de la fecha del servicio asociada a la primera transacción de cargo del evento de facturación. Tipo de evento inferred | |||
| Ajuste de cuenta realizado | Esta actividad representa una transacción que no es un pago y modifica el saldo de la cuenta, como un ajuste contractual, la condonación de un saldo pequeño o un descuento de cortesía. Se registra con un tipo de transacción específico. | ||
| Por qué es importante Analizar los ajustes es clave para detectar pérdidas de ingresos. Un volumen elevado de ciertos tipos de ajustes puede indicar problemas con las tarifas, los contratos o las políticas internas. Dónde obtenerlo Se registra explícitamente como una transacción de ajuste en los registros financieros de Resolute. Cada ajuste tiene asociado un tipo específico o un código de motivo. Capturar Filtre los tipos de transacción correspondientes a ajustes financieros o condonaciones. Tipo de evento explicit | |||
| Inicio del seguimiento de un rechazo | Esta actividad marca el inicio del proceso interno para revisar y resolver una reclamación rechazada. A menudo se registra cuando una persona se hace cargo de la reclamación en una cola de trabajo o cambia su estado. | ||
| Por qué es importante El seguimiento de esta actividad permite medir la capacidad de respuesta del equipo de gestión de rechazos. Las demoras entre el rechazo y el inicio del seguimiento pueden prolongar innecesariamente el ciclo de ingresos. Dónde obtenerlo Suele inferirse a partir de los cambios de estado de la reclamación o del historial de asignaciones en las colas de trabajo de Epic. Por ejemplo, el estado de la reclamación puede cambiar de 'Rechazada' a 'En revisión'. Capturar Infiera el evento a partir de un cambio en el estado de la reclamación o de una entrada del registro de auditoría que indique que una persona ha empezado a gestionar el rechazo. Tipo de evento inferred | |||
| Reclamación generada | Esta actividad indica que el sistema ha creado una reclamación o factura formal a partir de los cargos capturados. Es un paso preparatorio antes de enviar la reclamación al pagador o al paciente. | ||
| Por qué es importante El seguimiento de la generación de reclamaciones ayuda a detectar demoras entre la captura de los cargos y su preparación para el envío. Es un paso interno clave que puede afectar a los plazos generales de facturación. Dónde obtenerlo Suele registrarse cuando se ejecuta un proceso por lotes de generación de facturas o reclamaciones. El sistema registra la marca de tiempo en que se crea el archivo de reclamación, como un archivo 837, para una cuenta determinada. Capturar Identifique las entradas del registro o los cambios de estado que indiquen que la reclamación se ha preparado y está lista para enviarse. Tipo de evento explicit | |||
| Reclamación reenviada | Este evento ocurre después de corregir una reclamación rechazada y volver a enviarla al pagador. Es un envío independiente vinculado a la reclamación original. | ||
| Por qué es importante Es una parte clave del ciclo de trabajo repetido. Medir el tiempo hasta el reenvío y la tasa de éxito de las reclamaciones reenviadas es fundamental para evaluar la eficacia del proceso de resolución de rechazos. Dónde obtenerlo Este evento se registra explícitamente, como el envío inicial, pero suele marcarse como reenvío. El registro de la reclamación muestra una nueva marca de tiempo de envío y puede incluir un código de reenvío. Capturar Capture la marca de tiempo del envío de una reclamación marcada como corrección o reenvío. Tipo de evento explicit | |||
| Saldo enviado a cobro | Este evento marca el momento en que un saldo impagado se transfiere a un proceso de cobro interno o externo. A menudo se registra como un cambio explícito en el estado de la cuenta o del evento de facturación. | ||
| Por qué es importante Esta actividad inicia la etapa final de recuperación de saldos impagados. El seguimiento de la tasa de éxito y del tiempo de ciclo del proceso de cobro es fundamental para reducir las deudas incobrables. Dónde obtenerlo Suele ser un evento explícito. Epic permite transferir cuentas a agencias de cobro, lo que genera una entrada en el registro o un cambio de estado en la cuenta. Capturar Identifique el cambio de estado o la transacción que indica que una cuenta se ha asignado a una agencia de cobro. Tipo de evento explicit | |||
Guías de extracción
Pasos
- Establezca la conexión con la base de datos: Obtenga credenciales de solo lectura para la base de datos Epic Clarity. Conéctese al servidor de bases de datos con un cliente SQL estándar, como DBeaver o Microsoft SQL Server Management Studio.
- Identifique las tablas principales: Las tablas principales para esta extracción son
HSP_ACCOUNT, para la información de los casos;HSP_TRANSACTIONS, para los eventos financieros;CLP_CLAIM_INFO, para el estado de las reclamaciones; yF_ARHB_TX_SET_POST_HX, para los detalles de contabilización de pagos. También deberá unir archivos maestros, comoCLARITY_EMP, para obtener los datos de las personas usuarias. - Defina el alcance: Antes de escribir la consulta, determine el alcance del análisis. Defina un intervalo de fechas concreto, normalmente de 3 a 6 meses, e identifique las áreas de servicio hospitalario (
SERV_AREA_ID) o las clases de cuenta que desea incluir o excluir. - Desarrolle la consulta SQL: Construya una consulta SQL con una expresión de tabla común (CTE) para seleccionar primero los valores de
HSP_ACCOUNT_IDque se encuentren dentro del alcance definido. Este conjunto será la población base de eventos de facturación. - Una las consultas de cada actividad: Para cada una de las 12 actividades requeridas, escriba una instrucción
SELECTindependiente que recupere datos de las tablas pertinentes. Únala a la CTE inicial para asegurarse de analizar únicamente las cuentas previstas. - Combine las consultas con UNION ALL: Utilice el operador
UNION ALLpara combinar los resultados de todas las consultas de actividades en un único Registro de eventos coherente. Así, las filas de cada consulta se apilan verticalmente. - Adapte los datos al esquema estándar: En cada instrucción
SELECT, asigne alias a las columnas para que coincidan con el esquema requerido por ProcessMind:BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, etc. UtiliceNULLpara los atributos que no correspondan a una actividad concreta. - Ejecute y ajuste la consulta: Ejecute la consulta completa en la base de datos Clarity. Debido al tamaño de las tablas, puede tardar bastante. Si el rendimiento es un problema, reduzca el intervalo de fechas o añada filtros más específicos en la CTE inicial.
- Revise los resultados: Cuando termine la consulta, inspeccione las primeras centenas de filas. Compruebe que estén presentes todas las columnas, que las marcas de tiempo tengan un formato uniforme y que aparezcan los distintos valores de
ActivityNamesegún lo previsto. - Exporte a CSV: Exporte todo el conjunto de resultados desde el cliente SQL a un archivo CSV. Asegúrese de que el archivo use codificación UTF-8 e incluya una fila de encabezado con los nombres de columna correctos.
- Prepare el archivo para cargarlo: Antes de cargarlo en ProcessMind, abra el archivo CSV y compruebe que no haya errores de formato. Verifique que las marcas de tiempo tengan un formato uniforme, por ejemplo,
YYYY-MM-DD HH:MI:SS. El archivo estará listo para la ingesta.
Configuración
- Conexión a la base de datos: Se necesita una cuenta de usuario de solo lectura con acceso a la base de datos Epic Clarity.
- Parámetros del intervalo de fechas: La consulta proporcionada utiliza las variables
@StartDatey@EndDate. Debe asignarles valores para definir el periodo de análisis. Se recomienda un intervalo de 3 a 6 meses para equilibrar el volumen de datos y el rendimiento. - Asignación de tablas y columnas: La consulta presupone que se utilizan los nombres estándar de tablas y columnas de Clarity. La configuración o versión de Epic de su organización puede variar. Es posible que deba ajustar los nombres de tablas y columnas o las condiciones de unión.
- Códigos de transacción y estado: La consulta incluye marcadores de posición como
[Your Denial Tx Type]y[Your Collections Status Code]. Consulte a las personas administradoras de Epic o revise los archivos maestros pertinentes, comoZC_TX_TYPEoZC_ACCOUNT_STATUS, para encontrar los códigos correctos de su instancia. - Filtrado: Para mejorar el rendimiento y centrar el análisis, añada filtros a la CTE inicial
BaseAccounts. Entre los filtros habituales se incluyenSERV_AREA_ID, para limitar los resultados por área de servicio hospitalario, oACCOUNT_CLASS_C, para centrarse en la facturación de pacientes hospitalizados o ambulatorios.
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
- Confirme que dispone de acceso autorizado al conjunto de datos del ciclo de ingresos de Epic Clarity, incluidas las tablas y vistas de origen necesarias para consultar el historial de cuentas, cargos, reclamaciones, denegaciones, pagos, ajustes, cobros y cierres. Las tablas disponibles y los nombres de las columnas varían entre organizaciones que utilizan Epic. Por ello, asigne cada marcador de posición de la consulta al objeto de Clarity correspondiente en su entorno.
- Defina el periodo de extracción mediante [Start date parameter] y [End date parameter]. Empiece con un periodo de tres a seis meses y amplíelo solo después de validar el rendimiento de la consulta y la integridad de los eventos.
- Establezca la asignación de BillingEvent. Cuando esté disponible, la consulta utiliza HSP_ACCOUNT.HSP_ACCOUNT_ID como identificador de caso predeterminado. Si su organización define un evento de facturación a nivel de cargo, reclamación o encuentro, sustituya la asignación por el identificador aprobado y manténgalo de forma coherente en todas las fuentes de actividad.
- Asigne a cada actividad de origen una marca de tiempo y un atributo de origen fiables. Para Service Rendered, utilice la marca de tiempo documentada de finalización del servicio o del encuentro. Para Charges Captured, utilice la marca de tiempo de contabilización del cargo. Para Claim Generated y Claim Submitted to Payer, utilice las marcas de tiempo correspondientes al ciclo de vida de la reclamación. Las denegaciones, el seguimiento, los reenvíos, los pagos, los ajustes, los cobros y el cierre deben utilizar las marcas de tiempo documentadas de las transacciones o los estados.
- Sustituya todos los marcadores de posición de origen entre corchetes de la consulta, incluidos [Your service source table], [Your charge source table], [Your claim source table], [Your denial source table], [Your follow-up source table], [Your payment source table], [Your adjustment source table], [Your collections source table] y [Your account closure source table]. No utilice códigos de transacción sin documentación. Utilice los valores de transacción o estado aprobados por el equipo de informes de Epic de su organización.
- Ejecute la consulta en el cliente SQL o la plataforma de informes aprobados por su organización. Confirme que se devuelvan como filas explícitas las doce etiquetas de actividad. ProcessMind no infiere eventos del ciclo de vida que falten a partir de saldos, estados ni del orden de los eventos.
- Revise el esquema de salida. El resultado debe incluir BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance y ServiceType. Conserve las marcas de tiempo con la documentación de la zona horaria o la hora local y, si está permitido, mantenga los identificadores de origen en un extracto interno de auditoría.
- Valide el orden cronológico dentro de cada BillingEvent, el tratamiento de duplicados, las tasas de valores nulos, el recuento de actividades y la conciliación con los informes del sistema de origen. Investigue los eventos fuera del periodo solicitado que sean necesarios para interpretar casos iniciados antes o finalizados después de ese periodo.
- Exporte el resultado como archivo delimitado o mediante una conexión a una base de datos compatible con ProcessMind. Utilice una fila por evento, nombres de columna estables, un formato uniforme para las marcas de tiempo, codificación UTF-8 y ninguna celda combinada ni total de presentación. Al cargar los datos, configure BillingEvent como identificador del caso, ActivityName como actividad y EventTimestamp como marca de tiempo del evento.
Configuración
- Asignación de fuentes: Las implementaciones de Epic Clarity varían. Sustituya cada marcador de posición entre corchetes para objetos y columnas de origen por una tabla, vista o capa de informes documentada en su entorno. No dé por hecho que una tabla o un campo existe solo porque sea habitual en otra implementación de Epic.
- Identificador del caso: La asignación predeterminada de la consulta utiliza HSP_ACCOUNT.HSP_ACCOUNT_ID. Confirme si la organización define BillingEvent como una cuenta, un encuentro, una reclamación, un cargo u otra clave empresarial aprobada.
- Intervalo de fechas: Comience con un periodo de tres a seis meses. Incluya un periodo retrospectivo si los casos pueden comenzar antes de la ventana de informes y un periodo de seguimiento si las reclamaciones, denegaciones, pagos o cierres pueden producirse después de la fecha del servicio.
- Marcas de tiempo de las actividades: Configure una marca de tiempo de referencia para cada actividad. No sustituya la hora real del evento empresarial por la hora de extracción, de carga del archivo o del estado actual, salvo que esta última sea la marca de tiempo documentada del evento en el sistema de origen.
- Filtros: Aplique los filtros [Company Code filter], [Document Type filter], [Department filter], de pagador, área de servicio y clase de cuenta solo cuando sus definiciones estén documentadas y sean necesarios para el análisis. Mantenga los filtros uniformes en todas las ramas de UNION ALL.
- Asignación de transacciones y estados: Configure los valores aprobados por la organización para el registro de cargos, la creación y el envío de reclamaciones, las denegaciones, el seguimiento, el reenvío, la recepción y el registro de pagos, los ajustes, las cobranzas y el cierre. La consulta utiliza marcadores de posición intencionadamente, ya que los valores de transacción y las estructuras de origen de Epic varían según la implementación.
- Gestión de valores nulos: Conserve NULL en los atributos que no correspondan a una actividad. No sustituya los motivos de denegación o ajuste, los usuarios, los departamentos ni los tipos de servicio que falten por valores inventados.
- Rendimiento: Limite las filas de origen mediante columnas de fecha indexadas y filtros organizativos aprobados antes de unirlas con HSP_ACCOUNT. Evite aplicar funciones a columnas de marca de tiempo indexadas en las condiciones. Si el historial sin procesar es extenso, considere materializar cada actividad de origen en una vista de informes aprobada.
- Eliminación de duplicados: No elimine eventos duplicados sin una regla documentada. Varios pagos, ajustes, envíos o cambios de estado pueden ser eventos válidos para un mismo BillingEvent.
- Requisitos previos: Es posible que se requiera autorización para generar informes de Epic Clarity, acceso a los datos del ciclo de ingresos y al historial de cuentas, un entorno aprobado para ejecutar SQL y autorización de la organización para tratar información médica protegida. La disponibilidad del historial de reclamaciones, remesas, colas de trabajo, cobranzas y cierres depende de los módulos e interfaces de Epic con licencia e implementados.
Consulta de ejemplo sql
WITH
service_rendered AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Service Rendered' AS ActivityName,
CAST(s.[Service rendered timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(s.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(s.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(s.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(s.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your service source table] s
ON s.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE s.[Service rendered timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND s.[Service rendered timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND [Your company code filter]
),
charges_captured AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Charges Captured' AS ActivityName,
CAST(t.[Charge captured timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(t.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(t.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(t.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(t.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN AR_PB_TRANSACTIONS t
ON t.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE t.[Charge captured timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND t.[Charge captured timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND t.[Charge transaction filter]
AND [Your company code filter]
),
claim_generated AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Generated' AS ActivityName,
CAST(c.[Claim generated timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim generated timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim generated timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim generated status filter]
AND [Your company code filter]
),
claim_submitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
CAST(c.[Claim submitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim submitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim submitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim submitted status filter]
AND [Your company code filter]
),
claim_denied AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
CAST(d.[Denial timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(d.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(d.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(d.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(d.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(d.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your denial source table] d
ON d.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE d.[Denial timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND d.[Denial timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND d.[Denial status filter]
AND [Your company code filter]
),
denial_follow_up AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
CAST(f.[Follow-up timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(f.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(f.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(f.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(f.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(f.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your follow-up source table] f
ON f.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE f.[Follow-up timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND f.[Follow-up timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND f.[Follow-up status filter]
AND [Your company code filter]
),
claim_resubmitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
CAST(c.[Claim resubmitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim resubmitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted status filter]
AND [Your company code filter]
),
payment_received AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Received' AS ActivityName,
CAST(p.[Payment received timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment received timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment received timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment received status filter]
AND [Your company code filter]
),
payment_posted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
CAST(p.[Payment posted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment posted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment posted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment posted status filter]
AND [Your company code filter]
),
account_adjustment AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
CAST(x.[Adjustment timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(x.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(x.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(x.[Adjustment reason column] AS VARCHAR(100)) AS AdjustmentReason,
CAST(x.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(x.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your adjustment source table] x
ON x.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE x.[Adjustment timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND x.[Adjustment timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND x.[Adjustment transaction filter]
AND [Your company code filter]
),
balance_collections AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
CAST(k.[Collections timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(k.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(k.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(k.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(k.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your collections source table] k
ON k.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE k.[Collections timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND k.[Collections timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND k.[Collections status filter]
AND [Your company code filter]
),
account_closed AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Closed' AS ActivityName,
CAST(z.[Account closed timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(z.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(z.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(z.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(z.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your account closure source table] z
ON z.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE z.[Account closed timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND z.[Account closed timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND z.[Account closed status filter]
AND [Your company code filter]
)
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM service_rendered
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM charges_captured
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_generated
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_submitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_denied
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM denial_follow_up
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_resubmitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_received
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_posted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_adjustment
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM balance_collections
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_closed
ORDER BY BillingEvent, EventTimestamp, ActivityName; ¿Todo listo para empezar?
Aproveche todo el potencial de su proceso de gestión del ciclo de ingresos con datos precisos. Empiece hoy a mejorar la eficiencia y los resultados financieros.
Mejore al máximo la eficiencia: optimice ahora la gestión del ciclo de ingresos
Detecte ineficiencias de RCM en Epic Resolute y reduzca el tiempo de ciclo un 30 %.
No se requiere tarjeta de crédito. Empiece a optimizar hoy.