Su Template de datos para la gestión del ciclo de ingresos
Su Template de datos para la gestión del ciclo de ingresos
- Atributos recomendados para recopilar
- Actividades clave que conviene registrar
- Guía de extracción para Oracle Health Revenue Cycle
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 la entrega de un producto que genera un cargo. Sirve como identificador del caso en el proceso del ciclo de ingresos. | ||
| Descripción El evento de facturación funciona 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 específico. Cada evento de facturación representa una instancia única del proceso del ciclo de ingresos y permite seguirla en todas sus etapas, como el envío de reclamaciones, el registro de pagos 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 de facturación específicos. Por qué es importante Es la clave esencial para seguir 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 entender el momento y la secuencia de los eventos del ciclo de ingresos asociados a un evento de facturación específico. En el análisis, la marca de tiempo del evento permite ordenar las actividades cronológicamente, calcular la duración 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 temporales de Process Mining, como la identificación de retrasos entre «Reclamación enviada» y «Liquidación recibida». Por qué es importante Esta marca de tiempo es fundamental para ordenar los eventos, calcular métricas de rendimiento como los tiempos de ciclo y la duración, e identificar cuellos de botella en el 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 en el proceso del 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 «Cargos capturados», «Reclamación enviada al pagador» y «Pago registrado». Estas actividades forman los nodos del mapa de procesos descubierto. Analizar la secuencia y la frecuencia de las actividades es la base de Process Mining. Este atributo ayuda a identificar las rutas más habituales, detectar desviaciones del procedimiento estándar y entender el flujo operativo del ciclo de ingresos. Por qué es importante Define los pasos del proceso y permite visualizar el mapa de procesos y analizar los patrones del flujo de trabajo. Dónde obtenerlo Suele obtenerse de los registros de eventos, los registros de cambios de estado o las tablas de transacciones específicas de las distintas etapas del ciclo de ingresos en Oracle Health. Ejemplos Reclamación generadaLiquidación recibidaRechazo apeladoCuenta cerrada | |||
| Clase de paciente PatientClass | Clasificación del encuentro del paciente, como hospitalización o atención ambulatoria. | ||
| Descripción Este atributo clasifica el tipo de visita o encuentro del paciente que generó el cargo. Entre las categorías habituales se encuentran hospitalización, atención ambulatoria, urgencias y atención recurrente. La clase de paciente suele determinar todo el proceso de facturación y envío de reclamaciones. Cada clase de paciente sigue rutas de proceso distintas y tiene requisitos de cumplimiento diferentes. Analizar el proceso según este atributo ayuda a entender esas variaciones, adaptar las iniciativas de mejora y garantizar que se sigan los procedimientos correctos para cada clase. Por qué es importante Distingue flujos de proceso diferentes, como hospitalización y atención ambulatoria, que tienen distintos 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 de un paciente en Oracle Health. Ejemplos HospitalizaciónAtención ambulatoriaUrgenteRecurrente | |||
| Código del motivo de denegación DenialReasonCode | Código estandarizado que indica por qué el pagador denegó una reclamación. | ||
| Descripción Cuando un pagador deniega una reclamación, proporciona un código que explica el motivo, como «Servicio no cubierto» o «Reclamación duplicada». Este atributo registra el código y su descripción correspondiente. Analizar los motivos de denegación es fundamental para mejorar el ciclo de ingresos. Permite a la organización detectar 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 sin errores y reduce el coste del trabajo repetido. Por qué es importante Identifica la causa de fondo de las denegaciones de reclamaciones y permite aplicar mejoras específicas para aumentar la tasa de reclamaciones sin errores y acelerar el cobro de ingresos. Dónde obtenerlo El pagador envía esta información en el aviso electrónico de pago (archivo ANSI 835), que debe almacenarse en las tablas de reclamaciones o de avisos de pago de Oracle Health. Ejemplos CO-16: La reclamación o el servicio no incluye la información necesaria para su resolución.PR-96: Cargo(s) por servicios no cubiertos.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 que realizó la actividad, como «Captura de cargos», «Codificación» o «Cobros». Aporta contexto organizativo al flujo del proceso. Analizar el proceso desde la perspectiva de cada departamento es esencial para entender los traspasos entre equipos e identificar ineficiencias entre áreas. También permite usar el Dashboard «Carga de trabajo del departamento de facturación» para agrupar actividades y métricas de rendimiento por departamento. Por qué es importante Asigna las actividades a unidades de la organización, 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 en los datos del perfil de usuario de Oracle Health o derivarse de la persona usuaria o del tipo de actividad. Ejemplos Acceso de pacientesCodificaciónFacturaciónCobros | |||
| Importe del ajuste AdjustmentAmount | El valor monetario de los ajustes aplicados al saldo de la cuenta. | ||
| Descripción Este atributo registra el importe de cualquier ajuste financiero aplicado al evento de facturación, como bonificaciones contractuales, bajas o correcciones. Los ajustes reducen directamente los ingresos previstos de un cargo. El Dashboard «Impacto de los ajustes de cuenta» depende en gran medida de este atributo. Analizar los importes de los ajustes y los motivos asociados ayuda a identificar las causas de la pérdida de ingresos, los problemas de gestión de contratos o las deficiencias en el registro inicial de cargos. Es una métrica clave para evaluar la salud financiera. Por qué es importante Cuantifica la pérdida de ingresos por bajas o correcciones y ayuda a identificar y abordar las causas de la erosión financiera. Dónde obtenerlo Se encuentra en las tablas de transacciones financieras que registran ajustes o bajas en la cuenta de un paciente. Ejemplos -50.25-120.0025.00 | |||
| Nombre del pagador PayerName | Nombre de la aseguradora o del pagador externo responsable del pago. | ||
| Descripción Este atributo identifica a la entidad a la que se factura el servicio, como una aseguradora o un programa gubernamental como Medicare. La información del pagador es fundamental para analizar el ciclo de ingresos. Analizar el proceso por pagador puede revelar diferencias importantes en los tiempos de pago, las tasas de rechazo y el éxito de las apelaciones. Ayuda a identificar pagadores problemáticos que causan 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 descubrir diferencias de comportamiento, 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 en Oracle Health Revenue Cycle. Ejemplos AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Saldo pendiente OutstandingBalance | El saldo que aún no se ha pagado por el 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. Es un atributo crítico para el Dashboard «Antigüedad de saldos pendientes». Analizar este valor a lo largo del tiempo ayuda a supervisar la velocidad del flujo de caja, evaluar la eficacia de las gestiones de cobro y calcular KPI financieros clave, como los días pendientes de cobro (DSO). Por qué es importante Registra las cuentas por cobrar actuales de cada caso, un dato esencial para gestionar el flujo de caja y analizar la eficacia de los cobros. Dónde obtenerlo Este valor suele calcularse sumando todas las transacciones financieras (cargos, pagos y ajustes) de un evento de facturación. También puede existir como campo en una tabla de resumen de cuentas. Ejemplos 75.000.00550.80 | |||
| Usuario UserPerformingAction | ID o nombre de la persona usuaria que realizó la actividad. | ||
| Descripción Este atributo identifica a la persona empleada o al usuario del sistema automatizado responsable de realizar una actividad específica del proceso. Es fundamental para entender la distribución de la carga de trabajo, el rendimiento de los recursos y las necesidades de formación. En el análisis, permite filtrar el mapa de procesos por persona usuaria o equipo, comparar el rendimiento de distintos recursos y analizar la carga de trabajo en el Dashboard «Carga de trabajo del departamento de facturación». También puede ayudar a identificar a quienes obtienen mejores resultados o necesitan más apoyo o formación. 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 (por ejemplo, «CREATED_BY» y «USER_ID») suelen estar presentes en las tablas de transacciones de los distintos módulos de Oracle Health. Ejemplos j.doeasmithBillingBot_AUTOk.williams | |||
| Es automatizada IsAutomated | Indicador que señala si la actividad la realizó un sistema automatizado o una persona. | ||
| Descripción Este atributo booleano distingue las actividades ejecutadas mediante automatización de software, como bots o procesos por lotes del sistema, de las realizadas manualmente por una persona. Por ejemplo, «Reclamación generada» podría ser un paso automatizado, mientras que «Denegación apelada» probablemente sea 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. Permite comparar el rendimiento de las rutas automatizadas con el de las manuales e identificar oportunidades para ampliar la automatización. Por qué es importante Distingue las actividades realizadas por personas de las ejecutadas por sistemas, algo fundamental para analizar la eficacia de la automatización e identificar nuevas oportunidades. Dónde obtenerlo Este atributo suele derivarse de UserPerformingAction. Por ejemplo, las actividades realizadas por usuarios con ID como «SYSTEM» o «RPA_BOT» se marcan como automatizadas. Ejemplos truefalse | |||
| Es trabajo repetido IsRework | Indicador que identifica las actividades que representan trabajo repetido o esfuerzo duplicado. | ||
| Descripción Este atributo calculado marca las actividades que se desvían de la «ruta ideal» y generan trabajo repetido. Algunos ejemplos son «Reclamación corregida y enviada» o «Denegación apelada», que no se producirían si el proceso saliera bien a la primera. Identificar y cuantificar el trabajo repetido es uno de los objetivos clave de Process Mining. Este indicador facilita el filtrado y el análisis de todos los ciclos de trabajo repetido, y ayuda a 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 ciclos de trabajo repetido, y pone de manifiesto las ineficiencias del proceso y el coste de una calidad deficiente. Dónde obtenerlo Este atributo se deriva de otros datos. Se calcula durante la transformación de datos mediante reglas de negocio que marcan determinados nombres de actividad como trabajo repetido. Ejemplos truefalse | |||
| Hora de finalización del evento EventEndTime | Marca de tiempo que indica cuándo terminó una actividad, si está disponible. | ||
| Descripción Mientras que StartTime marca el inicio de una actividad, EventEndTime indica cuándo termina. No todas las actividades tienen una hora de finalización específica, ya que muchos eventos son instantáneos. Sin embargo, este campo resulta muy útil para las actividades que duran cierto tiempo, como «Rechazo apelado», cuyo procesamiento puede prolongarse. Este atributo permite calcular con mayor precisión el tiempo de procesamiento de cada actividad. Ayuda a distinguir entre el tiempo de espera, es decir, el intervalo entre actividades, y el tiempo de procesamiento, es decir, el tiempo dedicado a una actividad. Por qué es importante Permite calcular directamente cuánto tarda en completarse una actividad y distinguir el tiempo de procesamiento del tiempo de espera. Dónde obtenerlo Algunas tablas de transacciones de Oracle Health Revenue Cycle pueden incluir 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 la reclamación ClaimId | Identificador único de la reclamación de seguro presentada al pagador. | ||
| Descripción Este atributo es el ID único asignado a una reclamación que se genera y se envía al pagador para obtener el 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 corregirlo. El ID de la reclamación permite rastrear un envío específico al pagador y vincularlo directamente con la respuesta, como un pago o una denegación. Ofrece un 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 ante un pagador, con más detalle que el evento de facturación general. Dónde obtenerlo Oracle Health genera este ID al crear 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 número de historia clínica (MRN). Vincula la transacción financiera con una persona específica. Aunque no es el ID del caso del proceso, el ID del paciente permite agrupar todos los eventos de facturación de una persona y comprender su recorrido financiero completo. También permite segmentar los datos por características demográficas o antecedentes del paciente, si se combinan con los datos maestros de pacientes. Por qué es importante Vincula los eventos financieros con un paciente específico y permite analizar y agrupar todas sus actividades de facturación. Dónde obtenerlo Este identificador es un elemento central del registro maestro del paciente y aparece en todas las tablas de transacciones relacionadas, como las de cargos, reclamaciones y pagos. Ejemplos MRN-1002345MRN-1002346MRN-1002347 | |||
| Importe del cargo ChargeAmount | El valor monetario bruto del servicio o producto facturado. | ||
| Descripción Este atributo representa el importe inicial, sin descuentos, cobrado por un servicio antes de aplicar ajustes, bonificaciones contractuales o pagos. Es el valor financiero de partida del evento de facturación. Registrar el 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 posteriores. Sirve como referencia para medir los ingresos efectivamente percibidos. Por qué es importante Establece el valor financiero inicial del caso, fundamental para todos los análisis financieros y evaluaciones de impacto posteriores. Dónde obtenerlo Se encuentra en las tablas de detalles de cargos o transacciones de cargos de Oracle Health. Ejemplos 150.001250.7585.50 | |||
| Motivo de la disputa DisputeReason | Motivo que indica el cliente o paciente para disputar una factura o un cargo. | ||
| Descripción Este atributo registra el motivo por el que un paciente u otra persona responsable ha disputado una factura. Entre los motivos puede haber cargos incorrectos, servicios no prestados o problemas con la tramitación del seguro. Esta información es esencial para el Dashboard «Métricas de resolución de disputas de facturas». Conocer los motivos más frecuentes ayuda a detectar problemas sistémicos en el registro de cargos, la codificación o la facturación. Abordar estas causas de fondo 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 permite detectar directamente problemas de precisión o claridad en la facturación que deben corregirse. Dónde obtenerlo Es probable que esta información se almacene 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, suele ser «Oracle Health Revenue Cycle», aunque también puede indicar distintos módulos del sistema si los datos proceden de varias fuentes. Esta información es útil 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 Aporta contexto sobre el origen de los datos, algo fundamental para validarlos, aplicar la gobernanza y entender las variaciones del proceso que pueden depender del sistema. Dónde obtenerlo A menudo es un valor estático que se añade durante el proceso de extracción, transformación y carga (ETL) para indicar el origen del conjunto de datos. Ejemplos OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| Última actualización de los datos LastDataUpdate | Marca de tiempo que indica la última vez que se actualizaron o extrajeron los datos de este evento. | ||
| Descripción Este atributo indica cuándo se actualizó el conjunto de datos por última vez. Permite conocer la actualidad de los datos analizados, algo importante para valorar 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 establecer expectativas sobre la antigüedad de los datos y es un componente clave de la gobernanza y el control de calidad de los datos. Por qué es importante Indica la actualidad de los datos y ayuda a garantizar que el análisis y las decisiones se basen en información actualizada. Dónde obtenerlo Es un campo de metadatos que suele generarse y completarse 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 | Actividad final que indica que el saldo de la cuenta es cero y que no se esperan más movimientos. A menudo se infiere cuando el saldo llega a cero. | ||
| Por qué es importante Indica que el ciclo de ingresos se completó correctamente. El tiempo que se tarda en llegar a este estado es una medida clave de la eficiencia general del proceso. Dónde obtenerlo Suele inferirse al identificar la primera vez que el saldo pendiente de la cuenta llega a cero y permanece en cero después de registrar todos los pagos y ajustes. Capturar Se calcula cuando el saldo de la cuenta llega a cero por primera vez, una vez registrados todos los cargos y pagos. Tipo de evento calculated | |||
| Cuenta del paciente creada | Indica la creación de una cuenta de paciente para una visita o un servicio específicos. Suele ser un evento explícito que activa el sistema de registro o una fuente de datos de admisión, alta y traslado (ADT). | ||
| Por qué es importante Es el punto de partida de todo el ciclo de ingresos asociado 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 de registro de pacientes o ADT. Busque los eventos de creación del encuentro o la marca de tiempo más temprana asociada al encuentro o al número financiero. Capturar Evento registrado al registrar o admitir al 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 que registra una persona usuaria o 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 pueden distorsionar la situación financiera y demorar la facturación secundaria. Dónde obtenerlo Se encuentra en las tablas de transacciones de pagos. Cada registro de pago tiene un ID de transacción único y una marca de tiempo asociada. Capturar 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 aseguradora o al pagador. El sistema debe registrar la fecha y la hora de la transmisión. | ||
| Por qué es importante Esta actividad inicia el ciclo de pago. Analizar el tiempo entre el envío y el pago es fundamental para entender el rendimiento de los pagadores y los días pendientes de cobro (DSO). Dónde obtenerlo Se obtiene del módulo de gestión de reclamaciones, que registra los eventos de transmisión. Busque la marca de tiempo del envío o un cambio de estado a «Enviada» en el historial de la reclamación. Capturar Evento registrado cuando la reclamación se transmite correctamente a través de la cámara de compensación. Tipo de evento explicit | |||
| Reclamación generada | Indica el momento en que los cargos individuales se agrupan en una reclamación formal, como un formulario 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 enviarse al pagador. Marca el final del intervalo interno entre la captura del cargo y la facturación. Dónde obtenerlo Es un evento explícito registrado en los registros o las tablas de generación de reclamaciones. Busque la marca de tiempo de creación del registro principal de la reclamación asociado al encuentro. Capturar Evento registrado al crear el registro de la reclamación. Tipo de evento explicit | |||
| Cargos capturados | Representa el registro de servicios o artículos facturables en la cuenta del paciente. Puede realizarse automáticamente desde los sistemas clínicos o mediante el ingreso manual del personal. | ||
| Por qué es importante Esta actividad es fundamental para medir el retraso en la captura de cargos, es decir, el tiempo entre la prestación del servicio y el inicio de la facturación. Este intervalo afecta directamente al flujo de efectivo y a la integridad de los ingresos. Dónde obtenerlo Se obtiene de las tablas de transacciones de cargos, a partir de la marca de tiempo de creación de cada línea de cargo. En Oracle Health, suele encontrarse en tablas relacionadas con los cargos. Capturar Se crea una entrada en el registro de transacciones por cada cargo nuevo. Tipo de evento explicit | |||
| Cargos codificados | Representa el proceso en el que el personal de codificación médica asigna 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 detectar ineficiencias en el flujo de trabajo de codificación y a entender cómo afectan a 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 «Sin codificar» a «Codificado». Se necesita la marca de tiempo de ese cambio. Capturar Se infiere cuando el estado del encuentro o del cargo cambia a «Codificado» o «Listo para facturar». Tipo de evento inferred | |||
| Cuenta ajustada | Representa un ajuste financiero del saldo de la cuenta, como una bonificación contractual, una condonación 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 detectar pérdidas de ingresos e imprecisiones en la 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 específico y una marca de tiempo. Capturar Se registra una transacción financiera con un código de ajuste específico. Tipo de evento explicit | |||
| Estado de cuenta enviado al paciente | Indica que se generó y envió al paciente una factura por el saldo que le corresponde pagar. Es una acción explícita que registra el módulo de facturación a pacientes. | ||
| Por qué es importante Esto inicia la parte del ciclo de ingresos correspondiente a los pagos del paciente. El seguimiento permite 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. Capturar Evento registrado cuando se genera e imprime un estado de cuenta del paciente o se envía por medios electrónicos. Tipo de evento explicit | |||
| Gestión de cobro iniciada | Indica que la cuenta del paciente pasó a un proceso de cobro por falta de pago. Suele registrarse mediante un cambio en la categoría financiera o de estado de la cuenta. | ||
| Por qué es importante Este paso es fundamental para gestionar la deuda incobrable. Es esencial analizar qué conduce a esta etapa y cuál es su tasa de éxito para mantener la salud financiera. Dónde obtenerlo Se infiere a partir de un cambio en el campo de estado de la cuenta a «Cobros» o «Deuda incobrable». Este cambio debe tener una marca de tiempo asociada. Capturar Se infiere a partir de un cambio en el estado de la cuenta a «Cobros» o a un estado similar. Tipo de evento inferred | |||
| Liquidación recibida | Indica la recepción de un aviso electrónico de pago (ERA) o una explicación de beneficios en papel (EOB) del pagador. El documento detalla qué cargos se pagaron, se rechazaron o se ajustaron. | ||
| Por qué es importante Es la primera respuesta del pagador y resulta esencial para entender la velocidad de los pagos e identificar cuanto antes las tendencias de rechazo. Dónde obtenerlo Se registra en el módulo de procesamiento de liquidaciones. Busque la marca de tiempo de importación o creación del archivo ERA, como un archivo de transacción 835, vinculado a la reclamación. Capturar Evento registrado al importar y procesar el archivo de liquidación del pagador (por ejemplo, ANSI 835). 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. Suele registrarse como una actualización de estado o 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 la 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 «Apelada» o «En revisión». Capturar Cambio de estado o evento registrado cuando una persona usuaria inicia la apelación de una reclamación rechazada. Tipo de evento explicit | |||
| Rechazo recibido | Indica que el pagador rechazó una reclamación o determinadas líneas de cargo, según consta en el aviso de liquidación. A menudo, este evento se infiere a partir de los códigos de rechazo incluidos en los datos de liquidación. | ||
| Por qué es importante El seguimiento de los rechazos es esencial para identificar sus causas, como errores de codificación o problemas de elegibilidad, y mejorar la tasa de reclamaciones correctas desde el primer envío. Dónde obtenerlo Se infiere a partir de los datos de liquidación (ERA/835). El evento se activa cuando una reclamación o una línea de cargo tiene un importe de rechazo distinto de cero y un código de motivo de rechazo asociado. Capturar Se infiere a partir de datos de liquidación que contienen códigos de motivo de rechazo (CARC/RARC). Tipo de evento inferred | |||
| Reclamación corregida enviada | Representa el envío al pagador de una reclamación revisada o corregida, a menudo tras un rechazo o una solicitud de más información. Se identifica por 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 las reclamaciones iniciales. Dónde obtenerlo Se obtiene de los registros de envío de reclamaciones. Busque un nuevo envío para un encuentro existente, a menudo identificado por un código de reenvío o un número de iteración superior. Capturar Evento registrado para el reenvío de una reclamación, que suele identificarse mediante un código específico del tipo de frecuencia de la reclamación. Tipo de evento explicit | |||
Guías de extracción
Pasos
- Solicite acceso a la base de datos: Obtenga credenciales de solo lectura para la base de datos de Oracle Health Revenue Cycle. Necesitará acceso a los esquemas que contienen datos de pacientes, encuentros, facturación y transacciones financieras. Por lo general, los equipos de seguridad informática y administración de bases de datos deben aprobar el acceso.
- Identifique los nombres de los esquemas y las tablas: Consulte con una persona administradora de bases de datos o 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 debe adaptarlos a su entorno.
- Instale un cliente SQL: Instale en su equipo un cliente SQL compatible, como Oracle SQL Developer o DBeaver. Lo utilizará para conectarse a la base de datos y ejecutar el script de extracción.
- Establezca la conexión con la base de datos: Configure una nueva conexión en el cliente SQL con el host, el puerto, el nombre del servicio y las credenciales proporcionados. Pruebe la conexión para confirmar que funciona.
- Adapte la consulta SQL: Copie el script SQL proporcionado en una nueva ventana del editor de consultas. Busque 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 de análisis, por ejemplo, para filtrar por una clase de paciente específica. - Ejecute el script de extracción: Ejecute el script SQL adaptado. La consulta está diseñada para abarcar todos los datos necesarios y, según el intervalo de fechas y el tamaño de la base de datos, puede tardar desde varios minutos hasta varias horas.
- Revise los resultados iniciales: Cuando termine la consulta, revise las primeras centenas de filas en la cuadrícula de resultados del cliente SQL. Compruebe que no haya errores evidentes, como columnas completamente vacías o formatos de datos incorrectos, para confirmar que el script se ejecutó correctamente.
- Exporte los datos a CSV: Exporte todo el conjunto de resultados a un archivo CSV. Use la codificación UTF-8 para evitar problemas con los caracteres. Compruebe que el archivo exportado incluya una fila de encabezado con los nombres de columna definidos en los alias de la consulta (por ejemplo, "BillingEvent", "ActivityName").
- Prepare el archivo para cargarlo: Antes de cargar el archivo en una herramienta de Process Mining, ábralo para comprobar que esté íntegro. Verifique que el formato de las marcas de tiempo sea uniforme y que los encabezados de columna coincidan exactamente con los atributos requeridos. El archivo ya estará listo para cargarse.
Configuración
- Intervalo de fechas: La consulta usa los marcadores de posición
[START_DATE]y[END_DATE]. Es fundamental definir un intervalo de fechas concreto y razonable para controlar el volumen de datos. Para el análisis inicial, se recomienda un período 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áusulasWHEREen esta sección para delimitar el alcance; por ejemplo,e.patient_class_code IN ('INPATIENT', 'OUTPATIENT')permite centrarse en tipos de encuentro específicos. - Rendimiento: Consultar directamente una base de datos de producción puede afectar al rendimiento. Se recomienda encarecidamente ejecutar esta extracción fuera de las horas de mayor actividad o, si está disponible, en una réplica de solo lectura de la base de datos de producción.
- Requisitos previos: Este método requiere una cuenta de usuario de base de datos con privilegios
SELECTen todas las tablas mencionadas en la consulta. Estas incluyen tablas de encuentros, facturación, cargos, reclamaciones, remesas y transacciones financieras. - Asignación de tablas y columnas: El script proporcionado usa nombres habituales y representativos para las tablas y columnas. Debe validarlos y asignarlos a los nombres reales del esquema de Oracle Health de su organización. Por ejemplo, en su sistema,
FINANCIAL_TRANSACTIONpodría llamarseAR_TRANSACTIONS.
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; ¿Todo listo para comenzar?
Utilice este Template para preparar los datos y obtener buenos resultados. Comience hoy mismo a mejorar el proceso de gestión del ciclo de ingresos.
Optimice el ciclo de ingresos para recibir los pagos más rápido
Elimine cuellos de botella, reduzca el tiempo de ciclo un 30 % y mejore el flujo de caja.
No se requiere tarjeta de crédito. Configure todo en unos minutos.