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 debe supervisar
- Guía de extracción
Atributos de la gestión del ciclo de ingresos
| Nombre | Descripción | ||
|---|---|---|---|
| Evento de facturación BillingEvent | El 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 central que conecta todas las actividades del ciclo de ingresos de un artículo facturable específico. Comienza cuando se presta un servicio y concluye cuando la cuenta queda totalmente 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 hacer seguimiento de actividades como la captura del cargo, el envío de la reclamación, la contabilización del pago y la gestión de denegaciones de eventos de facturación individuales, ofreciendo una visión clara del flujo del proceso y sus variaciones. Por qué es importante Es el Case ID fundamental, esencial para vincular todos los pasos relacionados del proceso y analizar el ciclo de vida completo de la generación y el 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 conocer tablas específicas, como los registros HAR o Charge Session. Ejemplos BE10098765BE20012345BE30054321 | |||
| Marca de tiempo del evento EventTimestamp | La fecha y hora exactas en que ocurrió una actividad o un evento específico. | ||
| Descripción La marca de tiempo del evento registra el momento en que tuvo lugar una actividad. Estos datos temporales son fundamentales para comprender el momento y la secuencia de los eventos en el ciclo de ingresos. En el análisis, las marcas de tiempo se utilizan para calcular las duraciones entre actividades, como el retraso en la captura de cargos o el tiempo de contabilización de pagos. Permiten descubrir cuellos de botella, medir los tiempos de ciclo y analizar el rendimiento del proceso 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 identificar retrasos e ineficiencias. Dónde obtenerlo Se encuentra en las tablas de transacciones o registros de eventos de Epic Resolute, asociado a cada actividad registrada. Los campos suelen tener sufijos como Dt, DTTM o Time. Ejemplos 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Nombre de la actividad ActivityName | El nombre del evento o la tarea específicos realizados dentro del proceso de gestión del ciclo de ingresos. | ||
| Descripción Este atributo describe un paso individual 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 actividades es la base de Process Mining. Permite visualizar el mapa del proceso, identificar las rutas habituales, descubrir 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, lo que permite visualizar, analizar y optimizar el flujo de trabajo del ciclo de ingresos. Dónde obtenerlo Normalmente se deriva de registros de eventos, pistas de auditoría o 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 de denegación DenialReasonCode | Código estandarizado que indica el motivo por el que un pagador denegó una reclamación enviada. | ||
| Descripción Cuando un pagador rechaza una reclamación, proporciona un código de motivo que explica la denegación, como «Servicio no cubierto», «Reclamación duplicada» o «Requiere información adicional». Estos códigos suelen estar estandarizados como Claim Adjustment Reason Codes (CARC). Este atributo es la base del Dashboard «Tasas y motivos de denegación de reclamaciones». Analizar la frecuencia de los distintos códigos de denegación ayuda a identificar las causas raíz, 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 práctica para reducir las tasas de denegación, evitar pérdidas de ingresos y acelerar los pagos. Dónde obtenerlo Estos datos se encuentran en las transacciones de respuesta a reclamaciones, como un archivo ANSI 835, recibidas de los pagadores y almacenadas 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 | El departamento o equipo funcional responsable del evento o la actividad de facturación. | ||
| Descripción Este atributo indica la unidad organizativa, como «Facturación de pacientes hospitalizados», «Facturación ambulatoria» o «Equipo de gestión de denegaciones», asociada al evento de facturación o responsable de realizar una actividad específica. Esta dimensión es fundamental para el Dashboard «Métricas de rendimiento del departamento de facturación», ya que permite comparar lado a lado métricas clave, como las tasas de denegación o los tiempos de captura de cargos. Ayuda a la dirección a identificar los departamentos con mejor rendimiento, estandarizar las mejores prácticas y asignar recursos de forma eficaz. Por qué es importante Permite comparar el rendimiento entre distintos departamentos, ayudando a identificar mejores prácticas y áreas que necesitan mejoras o recursos adicionales. Dónde obtenerlo Esta información puede estar vinculada al registro del usuario, a la cuenta del paciente o a la ubicación del servicio en Epic Resolute. Ejemplos Facturación de cardiologíaRCM de radiologíaOficina central de facturación | |||
| Motivo del ajuste AdjustmentReason | El motivo 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. Los motivos pueden incluir acuerdos contractuales con pagadores, condonaciones de saldos pequeños o correcciones de errores de contabilización. Es esencial para el Dashboard «Volumen de ajustes de cuenta por tipo». Al analizar los motivos de los ajustes, las organizaciones pueden identificar fuentes de fugas de ingresos, comprender el impacto de los contratos con pagadores y detectar posibles ineficiencias o errores en el proceso de facturación. Por qué es importante Proporciona información sobre las fugas de ingresos y la precisión de la facturación al explicar por qué se modifican los saldos de las cuentas, lo que ayuda a reducir las condonaciones innecesarias. Dónde obtenerlo Se encuentra en los detalles de las transacciones correspondientes a entradas de ajustes del módulo de contabilidad de pacientes de Epic Resolute. Ejemplos Descuento contractualCancelación de saldo pequeñoCorrección de cargo duplicado | |||
| Saldo pendiente OutstandingBalance | El importe restante que el pagador o el paciente 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 el estado financiero 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 este valor a lo largo del tiempo y por dimensiones como el pagador o el departamento ayuda a priorizar los esfuerzos de cobro, 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 los cobros, gestionar 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 mediante transacciones financieras. Ejemplos 1500.00250.750.00 | |||
| Tipo de servicio ServiceType | La categoría o el 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». Proporciona contexto clínico a los datos financieros. Analizar el ciclo de ingresos por tipo de servicio puede revelar variaciones del proceso específicas de determinadas áreas clínicas. Por ejemplo, los procedimientos quirúrgicos pueden tener requisitos de captura de cargos y autorización más complejos que una consulta estándar, lo que genera comportamientos y desafíos diferentes en el proceso. Por qué es importante Proporciona contexto clínico a los datos financieros y permite analizar cómo los distintos tipos de servicios médicos afectan al proceso del ciclo de ingresos y a su eficiencia. Dónde obtenerlo Se deriva del catálogo maestro de cargos (CDM), la línea de servicio o el departamento asociado a la transacción de cargos en Epic. Ejemplos Cirugía hospitalariaRadiología ambulatoriaServicios de urgencias | |||
| Usuario responsable ResponsibleUser | El identificador del usuario o empleado que realizó la actividad. | ||
| Descripción Este atributo captura 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 la persona responsable de cobros que hizo seguimiento de una denegación. El análisis por usuario ayuda a identificar a quienes obtienen mejores resultados, detectar necesidades de formación y comprender la distribución de 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, lo que ayuda a identificar oportunidades de formación, desequilibrios en la carga de trabajo y cuellos de botella relacionados con los recursos. Dónde obtenerlo Normalmente se encuentra en las pistas de auditoría o los registros de transacciones de Epic Resolute, a menudo vinculado a una tabla maestra de usuarios, como el registro EMP. Ejemplos j.doebsmith123User7890 | |||
| Es automatizado IsAutomated | Indicador booleano que señala si la actividad fue realizada por un sistema o un proceso automatizado. | ||
| Descripción Este indicador distingue entre las tareas ejecutadas automáticamente por el sistema, como la generación automatizada de reclamaciones o las comprobaciones de elegibilidad, y las realizadas manualmente por un usuario. Analizar este atributo ayuda a comprender el nivel de automatización del proceso. Puede utilizarse para comparar la eficiencia y las tasas de error de las actividades automatizadas y manuales, identificar oportunidades de automatización adicional y supervisar el rendimiento de los bots o las reglas del sistema existentes. Por qué es importante Distingue entre actividades impulsadas por el sistema y actividades realizadas por personas, algo clave para evaluar el impacto de la automatización e identificar nuevas oportunidades de automatización. Dónde obtenerlo A menudo se deriva de comprobar si el «ResponsibleUser» de una actividad es una cuenta del sistema o de servicio, o de marcar nombres de actividad que se sabe que están automatizados. Ejemplos truefalse | |||
| Fecha de vencimiento del pago PaymentDueDate | La fecha en la que se espera recibir el pago por el servicio facturado. | ||
| Descripción Este atributo especifica el plazo de pago indicado en la factura o determinado por los contratos con los pagadores. Sirve como referencia para medir la puntualidad de los pagos. La fecha de vencimiento del pago es esencial para crear 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 pueden clasificarse en intervalos de antigüedad, como 0-30 días o 31-60 días de vencimiento, lo que ayuda a priorizar los cobros 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 derivado 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 | La marca de tiempo que indica cuándo se completó una actividad, útil para calcular su duración. | ||
| Descripción Este atributo registra la hora de finalización de una actividad. Aunque muchas actividades son eventos instantáneos en los que StartTime es igual a EndTime, algunas tareas tienen una duración medible, como una llamada de seguimiento de una denegación. Cuando está disponible, EndTime permite calcular directamente el tiempo de procesamiento de la actividad («EndTime» - «StartTime»). Esto 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 | El 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, como CMS-1500 o UB-04, enviado a un pagador. Un mismo evento de facturación puede incluir varias reclamaciones si los servicios se refacturan o se apelan. Hacer seguimiento por ID de reclamación resulta útil para analizar en detalle los subprocesos de envío de reclamaciones y gestión de denegaciones. Ayuda a distinguir las actividades relacionadas con la reclamación inicial de las asociadas 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 envío de reclamación específico, algo fundamental para analizar reenvíos y apelaciones. Dónde obtenerlo Lo genera 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 | |||
| ID del paciente PatientId | El 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 financiero de facturación con una persona específica. 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 utilizarse para agrupar todos los eventos de facturación de un paciente y comprender su recorrido financiero general. 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 específico, permite validar los datos y facilita un análisis más amplio de todo su recorrido, aunque debe gestionarse con cuidado por motivos de privacidad. Dónde obtenerlo Es un identificador fundamental presente en todo Epic, vinculado a los registros de registro y cuenta del paciente. Ejemplos MRN-1234567MRN-8765432MRN-5551234 | |||
| Importe ajustado AdjustedAmount | El valor monetario de una transacción de ajuste. | ||
| Descripción Este campo registra el importe específico del ajuste de una cuenta. Puede ser un valor positivo o negativo, que representa un crédito o un débito en el saldo de la cuenta. Este importe es la métrica principal del Dashboard «Volumen de ajustes de cuenta por tipo». Sumar este valor por motivo de ajuste ofrece una visión clara del impacto financiero de los distintos tipos de ajustes, como los ingresos condonados por obligaciones contractuales frente a los importes perdidos por errores corregibles. Por qué es importante Cuantifica el impacto financiero de los ajustes de cuenta y permite medir las fugas de ingresos y el coste de las imprecisiones de facturación. Dónde obtenerlo Se encuentra en las tablas de detalle de transacciones financieras de Epic Resolute, asociado a 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 al evento de facturación, como «Blue Cross Blue Shield», «Medicare» o «Aetna». En los casos de pago por cuenta propia, puede indicar al paciente. Segmentar el proceso por pagador es una técnica de análisis muy útil. Puede revelar que determinados 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 cada pagador para mejorar la eficiencia y acelerar los pagos. Por qué es importante Permite analizar el rendimiento por pagador, identificar cuáles tienen tasas de denegación 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, vinculados a la cuenta hospitalaria (HAR) en Epic Resolute. Ejemplos Medicare, parte BUnitedHealthcareAetna PPO | |||
| Sistema de origen SourceSystem | El sistema de información del que proceden los datos. | ||
| Descripción Este atributo identifica el sistema de origen del registro, que en este contexto es Epic Resolute. En entornos con varios sistemas integrados, este campo ayuda a diferenciar el origen de los datos. Aunque pueda parecer redundante en una vista de un solo sistema, es una buena práctica de gobierno y escalabilidad de datos. Garantiza la claridad si más adelante se integran datos de otros sistemas, como una plataforma independiente de una agencia de cobros. Por qué es importante Proporciona información esencial sobre el linaje y el contexto de los datos, garantizando claridad sobre su origen, algo fundamental para el gobierno de datos y la resolución de problemas. Dónde obtenerlo Normalmente es un valor estático añadido durante el proceso de extracción y transformación de datos para etiquetar el origen del conjunto de datos. Ejemplos Epic ResoluteEpicResolute_V2023 | |||
| Tiempo total del ciclo de ingresos TotalRevenueCycleTime | La duración total calculada desde el primer evento del servicio hasta el pago final o el cierre de la cuenta. | ||
| Descripción Es un KPI a nivel de caso que mide la duración de extremo a extremo del ciclo de ingresos de un evento de facturación individual. Normalmente se calcula como la diferencia de tiempo entre la actividad «Servicio prestado» y la actividad final «Pago recibido» o «Cuenta cerrada». Esta métrica de alto nivel ofrece una visión integral de la eficiencia general del proceso de gestión del ciclo de ingresos (RCM). Hacer 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 Ofrece una visión de alto nivel y de extremo a extremo de la eficiencia del proceso, midiendo directamente cuánto se tarda en convertir un servicio en efectivo. Dónde obtenerlo Es una métrica calculada en la herramienta de Process Mining mediante el filtrado del primer y el último evento de cada caso y el cálculo de la diferencia de tiempo. Ejemplos 259200038880005184000 | |||
| Última actualización de datos LastDataUpdate | La marca de tiempo que indica cuándo se actualizaron por última vez los datos de este evento o cuándo se extrajeron del sistema de origen. | ||
| Descripción Este atributo muestra la actualidad de los datos. Indica la última vez que el registro se extrajo de Epic Resolute y se incorporó al conjunto de datos de Process Mining. Es importante para comprender 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 comprender la vigencia de los datos analizados, algo fundamental para tomar decisiones empresariales precisas y actualizadas. Dónde obtenerlo Esta marca de tiempo la añade el proceso ETL (Extract, Transform, Load) durante la ingesta de datos. Ejemplos 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
Actividades de la gestión del ciclo de ingresos
| Actividad | Descripción | ||
|---|---|---|---|
| Cargos capturados | Representa el registro formal de los cargos facturables correspondientes a los servicios prestados. En Epic, normalmente se trata de una transacción explícita registrada en la cuenta del paciente, que suele generarse automáticamente a partir de acciones clínicas o introducirse manualmente. | ||
| Por qué es importante Este es un primer hito fundamental. 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 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, y suele encontrarse en tablas como ARPB_TRANSACTIONS. Recopilar 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, que indica que el saldo pendiente del evento de facturación ha llegado a cero y no quedan actividades pendientes. Puede deberse a un pago completo, ajustes o 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 de extremo a extremo, desde la prestación del servicio hasta el cierre, es un KPI fundamental de la eficiencia general del proceso. Dónde obtenerlo Normalmente es un evento inferido. Se determina identificando el momento en que el saldo de la cuenta correspondiente al evento de facturación llega a cero y permanece en cero. Recopilar Se infiere calculando el total acumulado del saldo 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 contabilizado en la cuenta | Este es el evento en el que 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 La contabilización eficiente de pagos es fundamental para mantener saldos de cuenta precisos y cerrar eventos de facturación. Permite identificar correctamente los saldos restantes para una facturación secundaria o para cobros. Dónde obtenerlo Es una transacción explícita en Resolute. La contabilización del pago vincula una transacción de pago con una o más transacciones de cargos, lo que queda registrado en las tablas de detalle de transacciones. Recopilar Capture el registro de la transacción que aplica un pago a un cargo, identificable mediante tipos de transacción específicos. Tipo de evento explicit | |||
| Pago recibido | Representa la recepción de un pago de un pagador o paciente. Este evento suele registrarse cuando se carga una remittance advice electrónica (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 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 se registran con una fecha, un origen y un importe, a menudo antes de contabilizarse por completo en cargos individuales. Recopilar Capture las transacciones de pago del registro de transacciones financieras, normalmente identificadas mediante tipos de transacción específicos. Tipo de evento explicit | |||
| Reclamación enviada al pagador | Marca el momento en que la reclamación se envía oficialmente al pagador del seguro para su evaluación. En Epic, es un evento registrado 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 crucial porque inicia el plazo de pago del pagador. Analizarlo ayuda a medir la eficiencia del proceso de transmisión de reclamaciones y respalda el KPI «Invoice to Payer Delivery Time». Dónde obtenerlo Es un evento explícito registrado en Resolute. El registro de la reclamación tendrá un estado de envío y una marca de tiempo que indicará cuándo se envió. Recopilar Capture la marca de tiempo asociada al cambio de estado de la reclamación a «Submitted» o «Transmitted». Tipo de evento explicit | |||
| Reclamación rechazada por el pagador | Representa la recepción de una notificación del pagador en la que se informa de que la reclamación ha sido rechazada. Se captura cuando Epic procesa un aviso electrónico de remesa, como un archivo 835, o cuando un usuario registra manualmente un rechazo. | ||
| Por qué es importante Esta actividad inicia un ciclo crítico de retrabajo. Analizar los motivos y el volumen de los rechazos es esencial para identificar las causas raíz, mejorar las tasas de pago en el primer envío y reducir los retrasos en la recaudación. Dónde obtenerlo Se registra explícitamente como una transacción o actualización de 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. Recopilar Filtre los tipos de transacción específicos o las actualizaciones de estado de reclamaciones 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, lo que inicia el evento de facturación. Normalmente se captura desde el EHR de Epic (EpicCare) cuando un profesional sanitario valida 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 de cargos es fundamental para identificar retrasos 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 registrada en la transacción del cargo es el dato clave. Recopilar 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 realizado en la cuenta | Esta actividad representa una transacción que no es un pago y que modifica el saldo de la cuenta, como un ajuste contractual, la condonación de un saldo pequeño o un descuento por cortesía. Se registra como un tipo de transacción específico. | ||
| Por qué es importante Analizar los ajustes es clave para identificar fugas de ingresos. Un volumen elevado de determinados tipos de ajuste 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 tendrá asociado un tipo específico o un código de motivo. Recopilar Filtre los tipos de transacción que correspondan a ajustes financieros o condonaciones. Tipo de evento explicit | |||
| Inicio del seguimiento del rechazo | Esta actividad marca el inicio del proceso interno para revisar y resolver una reclamación rechazada. Normalmente se captura cuando un usuario asume la responsabilidad de la reclamación rechazada en una cola de trabajo o cambia su estado. | ||
| Por qué es importante Su seguimiento ayuda a medir la capacidad de respuesta del equipo de gestión de rechazos. Los retrasos entre un rechazo y el inicio del seguimiento pueden prolongar innecesariamente el ciclo de ingresos. Dónde obtenerlo Normalmente se infiere a partir de los cambios en el estado de la reclamación o del historial de asignaciones dentro de las colas de trabajo de Epic. Por ejemplo, el estado de la reclamación puede cambiar de «Denied» a «In Review». Recopilar Infiera el evento a partir de un cambio de estado de la reclamación o de una entrada del registro de auditoría que muestre que un usuario ha comenzado 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 aislar los retrasos entre la captura de cargos y su preparación para el envío. Es un paso interno clave que puede afectar a la puntualidad general de la facturación. Dónde obtenerlo Normalmente se registra cuando se ejecuta un proceso por lotes de generación de facturas o reclamaciones. El sistema registra una marca de tiempo cuando se crea el archivo de reclamación, como un archivo 837, para una cuenta determinada. Recopilar Identifique las entradas del registro o los cambios de estado que indiquen que la reclamación se ha compilado y está lista para enviarse. Tipo de evento explicit | |||
| Reclamación reenviada | Este evento ocurre después de corregir una reclamación denegada y reenviarla al pagador. Es un evento de envío distinto, vinculado a la reclamación original. | ||
| Por qué es importante Esta es una parte clave del ciclo de retrabajo. Medir el tiempo hasta el reenvío y la tasa de éxito de las reclamaciones reenviadas es fundamental para comprender la eficacia del proceso de resolución de denegaciones. Dónde obtenerlo Es un evento explícito similar al envío inicial, pero a menudo se marca como reenvío. El registro de la reclamación mostrará una nueva marca de tiempo de envío y puede incluir un código de reenvío. Recopilar 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 cobros | Marca el momento en que un saldo de cuenta impagado se transfiere a un proceso de cobro interno o externo. A menudo se trata de un cambio de estado explícito en la cuenta o en el evento de facturación. | ||
| Por qué es importante Esta actividad inicia la etapa final de recuperación de saldos impagados. Hacer seguimiento de la tasa de éxito y del tiempo de ciclo del proceso de cobro es fundamental para minimizar la deuda incobrable. Dónde obtenerlo Normalmente es un evento explícito. Epic dispone de funciones para transferir cuentas a agencias de cobro, lo que crea una entrada de registro o un cambio de estado en la cuenta. Recopilar 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. Utilice un cliente SQL estándar, como DBeaver o Microsoft SQL Server Management Studio, para conectarse al servidor de la base de datos.
- Identifique las tablas principales: Las tablas principales para esta extracción incluyen
HSP_ACCOUNTpara la información de los casos,HSP_TRANSACTIONSpara los eventos financieros,CLP_CLAIM_INFOpara el estado de las reclamaciones yF_ARHB_TX_SET_POST_HXpara los detalles de contabilización de pagos. También deberá combinar archivos maestros comoCLARITY_EMPpara obtener los datos de los usuarios. - Defina el alcance: Antes de escribir la consulta, determine el alcance del análisis. Defina un intervalo de fechas específico, 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: Cree una consulta SQL mediante una Common Table Expression (CTE) para seleccionar primero el conjunto de valores
HSP_ACCOUNT_IDque se encuentran dentro del alcance definido. Este conjunto servirá como población base de los eventos de facturación. - Combine consultas de actividades individuales: Para cada una de las 12 actividades requeridas, escriba una instrucción
SELECTindependiente que recupere los datos de las tablas correspondientes. Vuelva a combinarla con 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 individuales en un único Registro de eventos coherente. De este modo, las filas de cada consulta se apilan verticalmente. - Asigne el 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 refine la consulta: Ejecute la consulta completa en la base de datos Clarity. Debido al tamaño de las tablas, puede tardar bastante tiempo. Si el rendimiento es insuficiente, reduzca aún más el intervalo de fechas o añada filtros más específicos en la CTE inicial.
- Revise el resultado: Cuando finalice la consulta, revise las primeras cientos de filas. Compruebe que todas las columnas estén presentes, que las marcas de tiempo tengan un formato coherente y que aparezcan los distintos valores de
ActivityNameesperados. - Exporte a CSV: Exporte todo el conjunto de resultados desde 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.
- Prepárese para la carga: Antes de cargar el archivo en ProcessMind, ábralo para confirmar que no contiene errores de formato. Compruebe que el formato de las marcas de tiempo sea coherente, por ejemplo,
YYYY-MM-DD HH:MI:SS. El archivo ya estará listo para su ingesta.
Configuración
- Conexión con 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 establecerlas 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 nombres estándar de tablas y columnas de Clarity. La configuración o la versión de Epic de su organización pueden presentar variaciones. Es posible que deba ajustar los nombres de tablas, los nombres de columnas o las condiciones de combinación.
- Códigos de transacción y estado: La consulta incluye marcadores como
[Your Denial Tx Type]y[Your Collections Status Code]. Debe consultar a los administradores de su sistema Epic o revisar los archivos maestros correspondientes, 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
BaseAccountsinicial. Entre los filtros habituales se incluyenSERV_AREA_IDpara limitar por área de servicio hospitalario oACCOUNT_CLASS_Cpara centrarse en la facturación de pacientes hospitalizados o ambulatorios.
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
- Confirme que dispone de acceso autorizado al conjunto de datos del ciclo de ingresos de Epic Clarity, incluidas las tablas de origen y las vistas necesarias para el historial de cuentas, cargos, reclamaciones, rechazos, pagos, ajustes, cobros y cierres. Las organizaciones que utilizan Epic pueden tener tablas y nombres de columnas diferentes, por lo que debe asignar cada marcador 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]. Utilice inicialmente 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. La consulta utiliza
HSP_ACCOUNT.HSP_ACCOUNT_IDcomo identificador de caso predeterminado cuando está disponible. 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 actividades. - Asigne cada actividad de origen a una marca de tiempo autorizada y a un atributo de origen. Service Rendered debe utilizar la marca de tiempo documentada de finalización del servicio o del encuentro. Charges Captured debe utilizar la marca de tiempo de contabilización del cargo. Claim Generated y Claim Submitted to Payer deben utilizar las marcas de tiempo correspondientes del ciclo de vida de la reclamación. Los rechazos, seguimientos, reenvíos, pagos, ajustes, cobros y cierres deben utilizar sus marcas de tiempo documentadas de transacción o estado.
- Sustituya todos los marcadores 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 sustituya códigos de transacción que no estén documentados. Utilice los valores de transacción o estado aprobados por su equipo de informes de Epic.
- Ejecute la consulta en el cliente SQL o la plataforma de informes aprobados por su organización. Confirme que las doce etiquetas de actividad se devuelvan como filas explícitas. ProcessMind no infiere eventos del ciclo de vida que falten a partir de saldos, estados u orden de los eventos.
- Revise el esquema de salida. El resultado debe contener BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance y ServiceType. Conserve las marcas de tiempo con la zona horaria o la documentación de hora local, y mantenga los identificadores de origen en una extracción de auditoría interna si está permitido.
- Valide el orden cronológico dentro de cada BillingEvent, el comportamiento de los duplicados, las tasas de valores nulos, los recuentos 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 dicho periodo.
- Exporte el resultado como archivo delimitado o mediante una conexión de base de datos compatible con ProcessMind. Utilice una fila por evento, nombres de columna estables, un formato de marca de tiempo coherente, codificación UTF-8 y ninguna celda combinada ni total de presentación. Configure BillingEvent como identificador del caso, ActivityName como actividad y EventTimestamp como marca de tiempo del evento durante la carga.
Configuración
- Asignación de fuentes: Las implementaciones de Epic Clarity varían. Sustituya cada objeto de origen y marcador de columna entre corchetes por una tabla, vista o capa de informes aprobada y 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 su organización define BillingEvent como una cuenta, un encuentro, una reclamación, un cargo u otra clave empresarial aprobada.
- Intervalo de fechas: Comience con tres a seis meses. Incluya un periodo retrospectivo cuando los casos puedan comenzar antes de la ventana de informes, y un periodo de seguimiento cuando las reclamaciones, los rechazos, los pagos o el cierre puedan producirse después de la fecha del servicio.
- Marcas de tiempo de las actividades: Configure una marca de tiempo autorizada para cada actividad. Evite sustituir la hora del evento empresarial real por la hora de extracción, la hora de carga del archivo o la hora 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 únicamente cuando sus definiciones estén documentadas y sean necesarios para el análisis. Mantenga los filtros coherentes en todas las ramas de UNION ALL.
- Asignación de transacciones y estados: Configure los valores aprobados por la organización para la contabilización de cargos, creación de reclamaciones, envío de reclamaciones, rechazos, seguimientos, reenvíos, recepción de pagos, contabilización de pagos, ajustes, cobros y cierres. La consulta utiliza marcadores intencionadamente porque 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 para los atributos que no correspondan a una actividad. No sustituya los motivos de rechazo, motivos de ajuste, usuarios, departamentos o tipos de servicio que falten por valores inventados.
- Rendimiento: Restrinja las filas de origen mediante columnas de fecha indexadas y filtros organizativos aprobados antes de combinarlas con HSP_ACCOUNT. Evite aplicar funciones a columnas de marca de tiempo indexadas en los predicados. Considere materializar cada actividad de origen en una vista de informes aprobada cuando el historial sin procesar sea muy grande.
- 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: El acceso necesario puede incluir autorización para informes de Epic Clarity, acceso a los datos del ciclo de ingresos y del historial de cuentas, un entorno aprobado para ejecutar SQL y autorización organizativa para acceder a información sanitaria protegida. La disponibilidad del historial de reclamaciones, remesas, colas de trabajo, cobros y cierres depende de los módulos e interfaces de Epic que estén licenciados e implementados.
a 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; ¿Listo para comenzar?
Descubra todo el potencial de su proceso de gestión del ciclo de ingresos con datos precisos. Comience hoy su camino hacia una mayor eficiencia y un mejor rendimiento financiero.
Alcance la máxima eficiencia: optimice ahora la gestión del ciclo de ingresos
Identifique las ineficiencias de RCM en Epic Resolute y reduzca el tiempo de ciclo en un 30 %.
No necesita tarjeta de crédito. Comience a optimizar hoy mismo.