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 seguir
- Guía de extracción para el ciclo de ingresos de Oracle Health
Atributos de la gestión del ciclo de ingresos
| Nombre | Descripción | ||
|---|---|---|---|
| Evento de facturación BillingEvent | Identificador único de la prestación de un servicio o producto que genera un cargo y que actúa como identificador de caso del proceso de ciclo de ingresos. | ||
| Descripción Billing Event actúa como identificador principal del caso y vincula todas las actividades, desde la captura del cargo hasta el cierre de la cuenta, para un artículo facturable concreto. Cada Billing Event representa una instancia única del proceso de ciclo de ingresos, lo que permite realizar un seguimiento completo de su recorrido por etapas como el envío de la reclamación, el registro del pago y los posibles rechazos o ajustes. En el análisis de Process Mining, este atributo es fundamental para reconstruir el flujo del proceso de principio a fin. Permite visualizar las variantes del proceso, calcular los tiempos de ciclo entre actividades e identificar cuellos de botella o desviaciones asociados a eventos facturables específicos. Por qué es importante Es la clave esencial para realizar el seguimiento de todo el ciclo de vida de un servicio facturable y permite analizar el flujo del proceso y medir su rendimiento. Dónde obtenerlo Este identificador debe ser una clave única presente en las tablas principales de facturación o de transacciones de cargos de Oracle Health Revenue Cycle. Consulte la documentación del sistema para identificar la clave principal de los eventos de cargos. Ejemplos BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Marca de tiempo del evento EventTimestamp | Fecha y hora exactas en que se registró una actividad en el sistema. | ||
| Descripción Este atributo proporciona la marca de tiempo de cada actividad y señala el momento exacto en que ocurrió. Es esencial para comprender el momento y la secuencia de los eventos del ciclo de ingresos correspondientes a un evento de facturación específico. En el análisis, Event Timestamp se utiliza para ordenar cronológicamente las actividades, calcular las duraciones y los tiempos de ciclo entre los distintos pasos y realizar análisis de cuellos de botella. Es la base de todas las métricas de Process Mining basadas en el tiempo, como la identificación de retrasos entre «Claim Submitted» y «Remittance Received». Por qué es importante Esta marca de tiempo es fundamental para ordenar los eventos, calcular todas las métricas de rendimiento, como los tiempos de ciclo y las duraciones, e identificar los cuellos de botella del proceso. Dónde obtenerlo Cada tabla de transacciones o de registros de eventos de Oracle Health Revenue Cycle debe tener una columna de marca de tiempo que indique cuándo se creó el registro o cuándo ocurrió el evento. Ejemplos 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Nombre de la actividad ActivityName | Nombre del paso o evento específico que tuvo lugar dentro del proceso de ciclo de ingresos. | ||
| Descripción Este atributo registra el nombre de cada actividad realizada durante el ciclo de vida de un evento de facturación. Algunos ejemplos son «Charges Captured», «Claim Submitted To Payer» y «Payment Posted». Estas actividades forman los nodos del mapa de procesos descubierto. El análisis de la secuencia y la frecuencia de las actividades constituye el núcleo de Process Mining. Este atributo ayuda a identificar las rutas de proceso más habituales, descubrir desviaciones respecto al procedimiento estándar y comprender el flujo operativo del ciclo de ingresos. Por qué es importante Define los pasos del proceso, lo que permite visualizar el mapa de procesos y analizar los patrones del Workflow. Dónde obtenerlo Normalmente se obtiene de registros de eventos, registros de cambios de estado o tablas de transacciones específicas asociadas a las distintas etapas del ciclo de ingresos en Oracle Health. Ejemplos Reclamación generadaRemesa recibidaRechazo apeladoCuenta cerrada | |||
| Clase de paciente PatientClass | Clasificación del encuentro del paciente, como Inpatient u Outpatient. | ||
| Descripción Este atributo categoriza el tipo de visita o encuentro del paciente que generó el cargo. Entre las clasificaciones habituales se incluyen Inpatient, Outpatient, Emergency y Recurring Patient. La clase de paciente suele determinar todo el proceso de facturación y envío de reclamaciones. Las distintas clases de pacientes siguen rutas de proceso diferentes y tienen requisitos de cumplimiento específicos. Analizar el proceso según este atributo ayuda a comprender estas variaciones, adaptar las iniciativas de mejora y garantizar que se sigan los procedimientos correctos para cada clase. Por qué es importante Separa flujos de proceso distintos, como Inpatient y Outpatient, que tienen diferentes niveles de complejidad, plazos y requisitos de facturación. Dónde obtenerlo Es un campo estándar asociado a un encuentro o registro de admisión del paciente en Oracle Health. Ejemplos HospitalizaciónAtención ambulatoriaUrgenciasRecurrente | |||
| Código del motivo de denegación DenialReasonCode | Código estandarizado que indica el motivo por el que el pagador denegó una reclamación. | ||
| Descripción Cuando un pagador deniega una reclamación, proporciona un código de motivo que explica la denegación, como «Servicio no cubierto» o «Reclamación duplicada». Este atributo registra dicho código y su descripción asociada. Analizar los motivos de denegación es fundamental para mejorar el ciclo de ingresos. Permite a la organización identificar patrones frecuentes, como problemas de codificación o de elegibilidad del paciente, y aplicar medidas correctivas para evitar futuras denegaciones. Esto repercute directamente en la tasa de reclamaciones limpias y reduce el coste del retrabajo. Por qué es importante Proporciona la causa raíz de las denegaciones de reclamaciones, lo que permite aplicar mejoras específicas para aumentar la tasa de reclamaciones limpias y acelerar la recaudación de ingresos. Dónde obtenerlo Esta información se recibe del pagador en el aviso electrónico de remesa (archivo ANSI 835) y debe almacenarse en las tablas de reclamaciones o remesas de Oracle Health. Ejemplos CO-16: a la reclamación o al servicio le falta información necesaria para la resolución.PR-96: cargo(s) no cubierto(s).CO-18: reclamación o servicio duplicado. | |||
| Departamento de facturación BillingDepartment | Departamento o equipo funcional responsable de la actividad. | ||
| Descripción Este atributo especifica el departamento, como «Charge Capture», «Coding» o «Collections», que realizó la actividad. Proporciona un contexto organizativo al flujo del proceso. Analizar el proceso desde la perspectiva departamental es esencial para comprender los traspasos entre equipos e identificar ineficiencias interfuncionales. También respalda el Dashboard «Billing Department Workload», ya que permite agregar actividades y métricas de rendimiento a nivel departamental. Por qué es importante Asigna las actividades a unidades organizativas, algo clave para analizar los traspasos entre departamentos, la carga de trabajo y el rendimiento de los equipos. Dónde obtenerlo Esta información puede almacenarse directamente con los datos del perfil de usuario en Oracle Health o derivarse a partir del usuario o del tipo de actividad. Ejemplos Acceso de pacientesCodificaciónFacturaciónCobros | |||
| Importe del ajuste AdjustmentAmount | Valor monetario de cualquier ajuste realizado en el saldo de la cuenta. | ||
| Descripción Este atributo registra el importe de cualquier ajuste financiero, como provisiones contractuales, bajas contables o correcciones, aplicado al evento de facturación. Los ajustes reducen directamente los ingresos previstos de un cargo. El Dashboard «Account Adjustment Impact» depende en gran medida de este atributo. Analizar los importes de los ajustes y sus motivos asociados ayuda a identificar fuentes de fugas de ingresos, problemas en la gestión de contratos o deficiencias en la captura inicial de cargos. Es una métrica clave de la salud financiera. Por qué es importante Cuantifica la fuga de ingresos causada por bajas contables o correcciones y ayuda a identificar y abordar las causas raíz de la erosión financiera. Dónde obtenerlo Se encuentra en las tablas de transacciones financieras que registran ajustes o bajas contables contra una cuenta de paciente. Ejemplos -50.25-120.0025.00 | |||
| Nombre del pagador PayerName | Nombre de la compañía de seguros o del pagador externo responsable del pago. | ||
| Descripción Este atributo identifica la entidad, como una compañía de seguros o un programa gubernamental como Medicare, a la que se factura el servicio. La información del pagador es fundamental para analizar el ciclo de ingresos. Analizar el proceso por pagador puede revelar variaciones significativas en los tiempos de pago, las tasas de rechazo y las tasas de éxito de las apelaciones. Ayuda a identificar a los pagadores problemáticos que provocan retrasos o pérdidas de ingresos y es esencial para gestionar eficazmente los contratos y las relaciones con los pagadores. Por qué es importante Permite segmentar el proceso por pagador y revelar diferencias en comportamientos, tasas de rechazo y velocidad de pago, aspectos fundamentales para el rendimiento financiero. Dónde obtenerlo Esta información se almacena en los registros de facturación o de seguros del paciente dentro de Oracle Health Revenue Cycle. Ejemplos AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Persona usuaria UserPerformingAction | ID o nombre de la persona que realizó la actividad. | ||
| Descripción Este atributo identifica a la persona empleada o al usuario del sistema automatizado responsable de ejecutar una actividad específica del proceso. Es fundamental para comprender la distribución de la carga de trabajo, el rendimiento de los recursos e identificar necesidades de formación. En el análisis, este atributo permite filtrar el mapa de procesos por persona usuaria o equipo, comparar el rendimiento de distintos recursos y analizar la carga de trabajo del Dashboard «Billing Department Workload». Puede ayudar a identificar a las personas con mejor rendimiento o a quienes necesitan apoyo o formación adicional. Por qué es importante Vincula las actividades del proceso con personas usuarias o equipos específicos, lo que permite analizar la carga de trabajo, comparar el rendimiento e identificar oportunidades de formación. Dónde obtenerlo Los campos de ID de usuario, como «CREATED_BY» o «USER_ID», suelen estar presentes en las tablas de transacciones de los distintos módulos de Oracle Health. Ejemplos j.doeasmithBillingBot_AUTOk.williams | |||
| Saldo pendiente OutstandingBalance | Saldo restante no pagado del evento de facturación en un momento determinado. | ||
| Descripción Este atributo muestra el importe pendiente actual de un evento de facturación después de aplicar todos los pagos y ajustes. Representa las cuentas por cobrar activas correspondientes a ese cargo específico. Es un atributo fundamental para el Dashboard «Outstanding Balance Aging». Analizar este valor a lo largo del tiempo ayuda a supervisar la velocidad del flujo de caja, evaluar la eficacia de los esfuerzos de cobro y calcular KPI financieros clave como el Days Sales Outstanding (DSO). Por qué es importante Realiza el seguimiento de las cuentas por cobrar actuales de cada caso, algo esencial para gestionar el flujo de caja y analizar la eficacia de los cobros. Dónde obtenerlo Este valor suele calcularse a partir de la suma de todas las transacciones financieras (cargos, pagos y ajustes) de un evento de facturación determinado. Puede existir como campo en una tabla de resumen de cuentas. Ejemplos 75.000.00550.80 | |||
| Es automatizado IsAutomated | Indicador que señala si la actividad fue realizada por un sistema automatizado o por una persona usuaria. | ||
| Descripción Este atributo booleano distingue entre las actividades ejecutadas mediante automatización de software, como bots o procesos por lotes del sistema, y las realizadas manualmente por una persona usuaria. Por ejemplo, «Reclamación generada» podría ser un paso automatizado, mientras que «Apelación de denegación» probablemente sería manual. Analizar este atributo ayuda a comprender el nivel de automatización del proceso y su impacto en la eficiencia y las tasas de error. Puede utilizarse para comparar el rendimiento de las rutas automatizadas y manuales, así como para identificar nuevas oportunidades de automatización. Por qué es importante Distingue entre las actividades realizadas por personas y las impulsadas por el sistema, algo fundamental para analizar la eficacia de la automatización e identificar nuevas oportunidades de automatización. Dónde obtenerlo Normalmente se deriva del atributo UserPerformingAction. Por ejemplo, las actividades realizadas por ID de usuario como «SYSTEM» o «RPA_BOT» se marcan como automatizadas. Ejemplos truefalse | |||
| Es retrabajo IsRework | Indicador que identifica las actividades que representan retrabajo o un esfuerzo repetido. | ||
| Descripción Este atributo calculado marca las actividades que indican una desviación de la «ruta ideal» y constituyen retrabajo. Algunos ejemplos son «Reclamación corregida enviada» o «Apelación de denegación», que no se producirían si el proceso se ejecutara correctamente desde el primer intento. Identificar y cuantificar el retrabajo es uno de los objetivos principales del Process Mining. Este indicador permite filtrar y analizar fácilmente todos los bucles de retrabajo, así como medir la frecuencia, el coste y las causas de las ineficiencias del proceso. Es esencial para comprender el coste real de la calidad en el ciclo de ingresos. Por qué es importante Ayuda a cuantificar la frecuencia y el impacto de los bucles de retrabajo, poniendo de relieve las ineficiencias del proceso y el coste de la mala calidad. Dónde obtenerlo Este es un atributo derivado. Se calcula durante la transformación de datos mediante una lógica empresarial que marca determinados nombres de actividad como retrabajo. Ejemplos truefalse | |||
| Hora de finalización del evento EventEndTime | Marca de tiempo que indica la finalización de una actividad, si está disponible. | ||
| Descripción Mientras que StartTime marca el inicio de una actividad, EventEndTime marca su conclusión. No todas las actividades tienen una hora de finalización diferenciada, ya que muchos eventos son instantáneos. Sin embargo, este campo resulta muy útil para las actividades que tienen una duración, como «Denial Appealed», cuyo procesamiento puede prolongarse. Este atributo permite calcular con mayor precisión el tiempo de procesamiento de cada actividad. Ayuda a diferenciar el tiempo de espera, es decir, el tiempo entre actividades, del tiempo de procesamiento, es decir, el tiempo dedicado a una actividad. Por qué es importante Permite calcular directamente cuánto tarda una actividad en completarse y separar el tiempo de procesamiento del tiempo de espera. Dónde obtenerlo Algunas tablas de transacciones de Oracle Health Revenue Cycle pueden contener marcas de tiempo de inicio y finalización para tareas específicas de larga duración. Ejemplos 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| ID de reclamación ClaimId | Identificador único de la reclamación de seguro presentada a un pagador. | ||
| Descripción Este atributo es el ID único asignado a una reclamación que se genera y se envía a un pagador para su reembolso. Un mismo evento de facturación puede dar lugar a una o varias reclamaciones a lo largo de su ciclo de vida, por ejemplo, si es necesario realizar una corrección. El Claim ID permite rastrear un envío específico al pagador y vincularlo directamente con la respuesta, como un pago o una denegación. Proporciona un nivel de seguimiento más detallado dentro del proceso general del ciclo de ingresos. Por qué es importante Proporciona un identificador específico para seguir el recorrido de una reclamación con un pagador, con un nivel de detalle superior al del evento de facturación general. Dónde obtenerlo Oracle Health genera este ID cuando se crea una reclamación y lo almacena en la tabla principal de reclamaciones. Ejemplos CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| ID del paciente PatientId | Identificador único del paciente asociado al evento de facturación. | ||
| Descripción Este atributo es el identificador único del paciente que recibió el servicio, conocido a menudo como Medical Record Number (MRN). Vincula la transacción financiera con una persona concreta. Aunque no es el ID del caso del proceso, el Patient ID resulta útil para agrupar todos los eventos de facturación de un mismo paciente y comprender todo su recorrido financiero. También permite segmentar los datos según la demografía o el historial del paciente si se combina con los datos maestros de pacientes. Por qué es importante Vincula los eventos financieros con un paciente concreto, lo que permite realizar análisis centrados en el paciente y agrupar todas sus actividades de facturación. Dónde obtenerlo Este identificador es un elemento esencial del registro maestro del paciente y estará presente en todas las tablas de transacciones relacionadas, como cargos, reclamaciones y pagos. Ejemplos MRN-1002345MRN-1002346MRN-1002347 | |||
| Importe del cargo ChargeAmount | Valor monetario bruto del servicio o producto que se factura. | ||
| Descripción Este atributo representa el importe inicial, sin descuentos, cobrado por un servicio antes de aplicar ajustes, provisiones contractuales o pagos. Es el valor financiero inicial del evento de facturación. El seguimiento del importe del cargo es fundamental para el análisis financiero, por ejemplo, para calcular el valor total de los servicios prestados y comprender el impacto financiero de los ajustes o las bajas contables posteriores. Sirve como referencia para medir la materialización de los ingresos. Por qué es importante Establece el valor financiero inicial del caso, que es fundamental para todos los análisis financieros posteriores y la evaluación de impacto. Dónde obtenerlo Se encuentra en las tablas de detalle de cargos o de transacciones de cargos de Oracle Health. Ejemplos 150.001250.7585.50 | |||
| Motivo de la disputa DisputeReason | Motivo proporcionado por el cliente o el paciente para disputar una factura o un cargo. | ||
| Descripción Este atributo registra el motivo por el que un paciente u otra parte responsable ha disputado una factura. Entre los motivos pueden encontrarse cargos incorrectos, servicios no prestados o problemas con la gestión del seguro. Esta información es esencial para el Dashboard «Métricas de resolución de disputas de facturas». Comprender los motivos más frecuentes de las disputas ayuda a identificar problemas sistémicos en los procesos de captura de cargos, codificación o facturación. Abordar estas causas raíz puede reducir considerablemente la tasa de disputas y la carga administrativa necesaria para resolverlas. Por qué es importante Explica por qué se disputan las facturas y proporciona información directa sobre los problemas de precisión o claridad de la facturación que deben corregirse. Dónde obtenerlo Probablemente se almacena en un módulo de gestión de casos o de atención al cliente de Oracle Health, vinculado a la cuenta del paciente. Ejemplos Servicio facturado incorrectamenteCargo duplicadoSeguro facturado incorrectamenteServicio no prestado | |||
| Sistema de origen SourceSystem | Sistema del que se extrajeron los datos del evento. | ||
| Descripción Este atributo identifica la aplicación o el módulo de origen de los datos. En este proceso, normalmente será «Oracle Health Revenue Cycle», aunque también puede especificar distintos módulos del sistema si los datos se integran desde varios lugares. Esta información es valiosa para la gobernanza de datos y la resolución de problemas. Ayuda a confirmar la trazabilidad de los datos y es importante en entornos donde varios sistemas contribuyen a un único proceso de principio a fin. Por qué es importante Proporciona contexto sobre el origen de los datos, algo fundamental para validarlos, gobernarlos y comprender las variaciones del proceso que pueden depender del sistema. Dónde obtenerlo A menudo es un valor estático añadido durante el proceso de extracción, transformación y carga (ETL) para etiquetar el origen del conjunto de datos. Ejemplos OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| Última actualización de datos LastDataUpdate | Marca de tiempo que indica la última vez que se actualizaron o extrajeron los datos de este evento. | ||
| Descripción Este atributo muestra cuándo se actualizó por última vez el conjunto de datos. Proporciona contexto sobre la actualidad de los datos analizados, algo importante para comprender la vigencia de la información obtenida mediante el análisis de Process Mining. Las personas usuarias pueden consultar este atributo para confirmar que están viendo la información más reciente del proceso. Ayuda a gestionar las expectativas sobre la antigüedad de los datos y es un componente clave de la gobernanza de datos y del control de calidad. Por qué es importante Indica la actualidad de los datos y garantiza que el análisis y las decisiones se basen en información actualizada. Dónde obtenerlo Es un campo de metadatos que normalmente se genera y completa durante el proceso ETL que carga los datos en la plataforma de Process Mining. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
Actividades de la gestión del ciclo de ingresos
| Actividad | Descripción | ||
|---|---|---|---|
| Cuenta cerrada | Es la actividad final e indica que el saldo de la cuenta es cero y que no se espera ninguna actividad adicional. A menudo se infiere cuando el saldo de la cuenta llega a cero. | ||
| Por qué es importante Indica la finalización satisfactoria del ciclo de ingresos. El tiempo necesario para alcanzar este estado es una medida clave de la eficiencia general del proceso. Dónde obtenerlo Normalmente se infiere identificando la primera vez que el saldo pendiente de la cuenta llega a cero y permanece en cero después de aplicar todos los pagos y ajustes. Recopilar Se calcula cuando el saldo de la cuenta es igual a cero por primera vez después de registrar todos los cargos y pagos. Tipo de evento calculated | |||
| Encuentro del paciente creado | Indica la creación de una cuenta de paciente para una visita o servicio específico. Normalmente es un evento explícito activado por el sistema de registro o por un feed de Admit/Discharge/Transfer (ADT). | ||
| Por qué es importante Sirve como punto de partida de todo el ciclo de ingresos correspondiente a un evento de facturación y permite analizar la duración total del proceso y la precisión del registro. Dónde obtenerlo Se obtiene de los registros del módulo Patient Registration o ADT. Busque eventos de creación de encuentros o la marca de tiempo más antigua asociada al encuentro o al número financiero. Recopilar Evento registrado durante el registro o la admisión del paciente. Tipo de evento explicit | |||
| Pago registrado | Representa la aplicación del pago recibido del pagador a los cargos correspondientes de la cuenta del paciente. Es una transacción financiera registrada por una persona usuaria o por un proceso automatizado. | ||
| Por qué es importante La eficiencia del registro de pagos afecta a la precisión de las cuentas por cobrar. Los retrasos en esta etapa pueden distorsionar la situación financiera y retrasar la facturación secundaria. Dónde obtenerlo Se encuentra en las tablas de transacciones de pagos. Cada registro de pago tendrá un ID de transacción único y una marca de tiempo asociada. Recopilar Se registra una transacción financiera cuando el pago se aplica a la cuenta. Tipo de evento explicit | |||
| Reclamación enviada al pagador | Representa el envío electrónico o en papel de la reclamación generada a la compañía de seguros o al pagador. El sistema debe registrar la fecha y hora de esta transmisión. | ||
| Por qué es importante Esta actividad inicia el ciclo de pagos. Analizar el tiempo transcurrido entre el envío y el pago es fundamental para comprender el rendimiento del pagador y el Days Sales Outstanding (DSO). Dónde obtenerlo Se obtiene del módulo de gestión de reclamaciones, que registra los eventos de transmisión. Busque una marca de tiempo de envío o un cambio de estado a «Submitted» en el historial de la reclamación. Recopilar Evento registrado cuando la reclamación se transmite correctamente a través del clearinghouse. Tipo de evento explicit | |||
| Reclamación generada | Indica el momento en que los cargos individuales se agrupan en una reclamación formal de facturación, como una UB-04 o CMS-1500. Es un evento generado por el sistema que crea la factura inicial. | ||
| Por qué es importante Es un hito importante que indica que la reclamación está lista para facturarse al pagador. Constituye el punto final para medir el «charge-to-bill lag» interno. Dónde obtenerlo Es un evento explícito registrado en los registros o tablas de generación de reclamaciones. Busque la marca de tiempo de creación del registro principal de la reclamación asociado al encuentro. Recopilar Evento registrado al crear el registro de la reclamación. Tipo de evento explicit | |||
| Actividad de cobro iniciada | Indica que la cuenta del paciente se ha transferido a un proceso de cobro debido a la falta de pago. Normalmente se captura mediante un cambio en la clase financiera o de estado de la cuenta. | ||
| Por qué es importante Es un paso fundamental para gestionar la deuda incobrable. Analizar qué conduce a esta etapa y su tasa de éxito es vital para la salud financiera. Dónde obtenerlo Se infiere a partir del cambio del campo de estado de la cuenta a «Collections» o «Bad Debt». Este cambio de estado debe tener una marca de tiempo asociada. Recopilar Se infiere a partir de un cambio del estado de la cuenta a «Collections» o a un estado similar. Tipo de evento inferred | |||
| Cargos capturados | Representa la introducción de servicios o artículos facturables en la cuenta del paciente. Puede producirse automáticamente desde sistemas clínicos o mediante la introducción manual por parte del personal. | ||
| Por qué es importante Esta actividad es fundamental para medir el «charge lag», es decir, el tiempo entre la prestación del servicio y el inicio de la facturación, que afecta directamente al flujo de caja y a la integridad de los ingresos. Dónde obtenerlo Se captura desde las tablas de transacciones de cargos, identificadas mediante la marca de tiempo de creación de cada línea de cargo. En Oracle Health, suele encontrarse en tablas relacionadas con los cargos. Recopilar Entrada del registro de transacciones creada para cada nuevo cargo. Tipo de evento explicit | |||
| Cargos codificados | Representa el proceso en el que los codificadores médicos asignan códigos estandarizados, como CPT o ICD-10, a los cargos capturados. A menudo se registra mediante un cambio de estado del cargo o del encuentro. | ||
| Por qué es importante Los retrasos en la codificación son un cuello de botella habitual. El seguimiento de esta actividad ayuda a identificar ineficiencias en el Workflow de codificación y su impacto en los plazos de facturación. Dónde obtenerlo A menudo se infiere a partir de un cambio de estado del encuentro del paciente o del lote de cargos, por ejemplo, de «Uncoded» a «Coded». Se necesita una marca de tiempo para este cambio de estado. Recopilar Se infiere a partir del cambio del estado del encuentro o del cargo a «Coded» o «Ready for Billing». Tipo de evento inferred | |||
| Cuenta ajustada | Representa un ajuste financiero realizado en el saldo de la cuenta, como una provisión contractual, una baja contable o un descuento. Cada ajuste es una transacción financiera independiente. | ||
| Por qué es importante Los ajustes afectan directamente a los ingresos. Analizar su frecuencia, tipo e importe ayuda a identificar fugas de ingresos e imprecisiones de facturación. Dónde obtenerlo Se encuentra en las tablas de transacciones financieras. Cada ajuste se registra como una línea independiente con un código de transacción y una marca de tiempo específicos. Recopilar Se registra una transacción financiera con un código de ajuste específico. Tipo de evento explicit | |||
| Estado de cuenta del paciente enviado | Indica el evento en el que se genera y envía al paciente una factura por el importe restante a su cargo. Es una acción explícita registrada por el módulo de facturación al paciente. | ||
| Por qué es importante Esto inicia la parte del ciclo de ingresos correspondiente al pago del paciente. Su seguimiento ayuda a analizar la eficacia de los cobros a pacientes. Dónde obtenerlo Se obtiene de los registros de facturación o correspondencia con pacientes. El sistema debe registrar la fecha en que se generó o envió cada estado de cuenta. Recopilar Evento registrado cuando se genera un estado de cuenta del paciente y se imprime o se envía electrónicamente. Tipo de evento explicit | |||
| Rechazo apelado | Acción de una persona usuaria o del sistema que indica que se está apelando una reclamación rechazada. Normalmente se captura como una actualización de estado o como una tarea específica creada en una cola de trabajo. | ||
| Por qué es importante Esta actividad inicia un ciclo de retrabajo. Analizar la frecuencia y la tasa de éxito de las apelaciones es fundamental para optimizar los esfuerzos de recuperación de ingresos. Dónde obtenerlo Puede tratarse de un evento explícito iniciado por una persona usuaria o inferirse a partir de un cambio de estado de la reclamación, como «Appealed» o «In Review». Recopilar Cambio de estado o evento registrado cuando una persona usuaria inicia el proceso de apelación de una reclamación rechazada. Tipo de evento explicit | |||
| Rechazo recibido | Indica el evento en el que el pagador rechaza una reclamación o determinadas líneas de cargo, según la información de la remesa. A menudo se infiere a partir de los códigos de rechazo presentes en los datos de la remesa. | ||
| Por qué es importante El seguimiento de los rechazos es esencial para identificar las causas raíz, como errores de codificación o problemas de elegibilidad, y mejorar la tasa de reclamaciones limpias. Dónde obtenerlo Se infiere a partir de los datos de la remesa (ERA/835). Cuando una reclamación o línea de cargo tiene un importe de rechazo distinto de cero y un código de motivo de rechazo asociado, se activa este evento. Recopilar Se infiere a partir de datos de remesas que contienen códigos de motivo de rechazo (CARC/RARC). Tipo de evento inferred | |||
| Reclamación corregida enviada | Representa el envío de una reclamación revisada o corregida al pagador, normalmente después de un rechazo o de una solicitud de información adicional. Se identifica mediante un nuevo envío de reclamación con un indicador de corrección. | ||
| Por qué es importante Esta actividad es una parte clave del ciclo de retrabajo de la gestión de rechazos. Una frecuencia elevada indica problemas con la precisión de la reclamación inicial. Dónde obtenerlo Se captura desde los registros de envío de reclamaciones. Busque un nuevo envío para un encuentro existente, normalmente marcado con un código de reenvío o un número de iteración superior. Recopilar Evento registrado correspondiente al reenvío de una reclamación, que suele identificarse mediante un código específico de tipo de frecuencia de reclamación. Tipo de evento explicit | |||
| Remesa recibida | Indica la recepción de un Electronic Remittance Advice (ERA) o una Explanation of Benefits (EOB) en papel por parte del pagador. Este documento detalla qué cargos se pagaron, rechazaron o ajustaron. | ||
| Por qué es importante Es la primera respuesta del pagador y resulta esencial para comprender la velocidad de los pagos e identificar a tiempo las tendencias de rechazo. Dónde obtenerlo Se registra en el módulo de procesamiento de remesas. Busque la marca de tiempo de importación o creación del archivo ERA, como un archivo de transacciones 835, vinculado a la reclamación. Recopilar Evento registrado al importar y procesar el archivo de remesas del pagador, por ejemplo, ANSI 835. Tipo de evento explicit | |||
Guías de extracción
Pasos
- Solicitar acceso a la base de datos: Obtenga credenciales de solo lectura para la base de datos de Revenue Cycle de Oracle Health. Necesitará acceso a los esquemas que contienen datos de pacientes, encuentros, facturación y transacciones financieras. Por lo general, esto requiere la aprobación de los equipos de seguridad informática y administración de bases de datos.
- Identificar los nombres de esquemas y tablas: Trabaje con un administrador de bases de datos o un analista de sistemas para confirmar los nombres exactos de los esquemas y las tablas de su instancia de Oracle Health. Los nombres incluidos en la consulta son marcadores de posición habituales y deben asignarse a su entorno específico.
- Instalar un cliente SQL: Instale en su equipo un cliente SQL compatible, como Oracle SQL Developer o DBeaver. Utilizará esta herramienta para conectarse a la base de datos y ejecutar el script de extracción.
- Establecer la conexión con la base de datos: Configure una nueva conexión en su cliente SQL con el host, el puerto, el nombre del servicio y las credenciales proporcionados. Pruebe la conexión para confirmar que funciona correctamente.
- Personalizar la consulta SQL: Copie el script SQL proporcionado en una nueva ventana del editor de consultas. Localice los valores de marcador de posición, como
[START_DATE]y[END_DATE], y sustitúyalos por el intervalo de fechas que desea analizar, por ejemplo, '2023-01-01'. Ajuste las condiciones de filtro según sus necesidades analíticas, como el filtrado por una clase de paciente concreta. - Ejecutar el script de extracción: Ejecute el script SQL personalizado. La consulta está diseñada para ser exhaustiva y puede tardar desde varios minutos hasta varias horas, según el intervalo de fechas y el tamaño de su base de datos.
- Revisar los resultados iniciales: Cuando finalice la consulta, revise las primeras cientos de filas en la cuadrícula de resultados de su cliente SQL. Compruebe que no haya errores evidentes, como columnas completamente nulas o formatos de datos incorrectos, para confirmar que el script se ejecutó correctamente.
- Exportar los datos a CSV: Exporte todo el conjunto de resultados a un archivo CSV. Utilice la codificación UTF-8 para evitar problemas con los caracteres. Asegúrese de que el archivo exportado incluya una fila de encabezado con los nombres de columna especificados en los alias de la consulta, por ejemplo, "BillingEvent" y "ActivityName".
- Preparar la carga: Antes de cargar el archivo en una herramienta de Process Mining, ábralo para confirmar que está íntegro. Compruebe que el formato de las marcas de tiempo sea coherente y que los encabezados de columna coincidan exactamente con los Atributos requeridos. El archivo ya está listo para cargarse.
Configuración
- Intervalo de fechas: La consulta utiliza los marcadores de posición
[START_DATE]y[END_DATE]. Es fundamental definir un intervalo de fechas específico y razonable para controlar el volumen de datos. Para el análisis inicial, se recomienda un intervalo de 3 a 6 meses. - Filtrado: El conjunto de datos inicial se filtra por la fecha de registro del encuentro (
reg_dt_tm) en la secciónRelevantEncounters. Puede añadir otras cláusulasWHEREa esta sección para limitar el alcance, por ejemplo,e.patient_class_code IN ('INPATIENT', 'OUTPATIENT')para centrarse en tipos de encuentro específicos. - Rendimiento: Las consultas directas a una base de datos de producción pueden afectar al rendimiento. Se recomienda encarecidamente ejecutar esta extracción fuera de las horas punta o contra una réplica de solo lectura de la base de datos de producción, si está disponible.
- Requisitos previos: Este método requiere una cuenta de usuario de base de datos con privilegios
SELECTsobre todas las tablas a las que hace referencia la consulta. Estas tablas incluyen tablas de encuentros, facturación, cargos, reclamaciones, remesas y transacciones financieras. - Asignación de tablas y columnas: El script proporcionado utiliza nombres habituales y representativos para tablas y columnas. Debe validarlos y asignarlos a los nombres reales del esquema de base de datos Oracle Health de su organización. Por ejemplo,
FINANCIAL_TRANSACTIONpodría llamarseAR_TRANSACTIONSen su sistema.
a Consulta de ejemplo sql
WITH RelevantEncounters AS (
SELECT
e.billing_event_id
FROM ENCOUNTER e
WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
e.billing_event_id AS "BillingEvent",
'Patient Encounter Created' AS "ActivityName",
e.reg_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cd.billing_event_id AS "BillingEvent",
'Charges Captured' AS "ActivityName",
cd.charge_entry_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cd.charge_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
ch.billing_event_id AS "BillingEvent",
'Charges Coded' AS "ActivityName",
ch.coded_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cl.billing_event_id AS "BillingEvent",
'Claim Generated' AS "ActivityName",
cl.create_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Claim Submitted To Payer' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
ra.billing_event_id AS "BillingEvent",
'Remittance Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Payment Posted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
rd.billing_event_id AS "BillingEvent",
'Denial Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
at.billing_event_id AS "BillingEvent",
'Denial Appealed' AS "ActivityName",
at.appeal_filed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Corrected Claim Submitted' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
psl.billing_event_id AS "BillingEvent",
'Patient Statement Sent' AS "ActivityName",
psl.statement_sent_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
psl.statement_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
ash.billing_event_id AS "BillingEvent",
'Collection Activity Started' AS "ActivityName",
ash.status_change_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ash.account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Account Adjusted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
ft.transaction_amount AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
e.billing_event_id AS "BillingEvent",
'Account Closed' AS "ActivityName",
e.account_closed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
0 AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL; ¿Listo para comenzar?
Aproveche esta plantilla para preparar sus datos y obtener los mejores resultados. Empiece hoy mismo a transformar su proceso de gestión del ciclo de ingresos.
Optimice su ciclo de ingresos para recibir pagos más rápido
Elimine los cuellos de botella, reduzca el tiempo de ciclo un 30 % y aumente el flujo de caja.
No necesita tarjeta de crédito. Configúrelo en cuestión de minutos.