Su Plantilla de Datos de Gestión del Ciclo de Ingresos
Su Plantilla de Datos de Gestión del Ciclo de Ingresos
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía de Extracción para el Ciclo de Ingresos de Oracle Health
Atributos de Gestión del Ciclo de Ingresos
| Nombre | Descripción | ||
|---|---|---|---|
| Billing Event BillingEvent | El identificador único para la entrega de un solo servicio o producto que genera un cargo, sirviendo como identificador de caso para el proceso del ciclo de ingresos. | ||
| Descripción El Evento de Facturación actúa como identificador principal de caso, vinculando todas las actividades desde la captura de cargos hasta el cierre de cuenta para un artículo facturable distinto. Cada Evento de Facturación representa una instancia única del proceso del ciclo de ingresos, permitiendo un seguimiento exhaustivo de su recorrido a través de varias etapas, como la presentación de reclamaciones, la contabilización de pagos y posibles denegaciones o ajustes. En el análisis de Process Mining, este atributo es fundamental para reconstruir el flujo de proceso de principio a fin. Permite la visualización de variantes de proceso, el cálculo de tiempos de ciclo entre actividades y la identificación de cuellos de botella o desviaciones asociadas con eventos de facturación específicos. Por qué es importante Esta es la clave esencial para rastrear todo el ciclo de vida de un servicio facturable, permitiendo todo el análisis del flujo de proceso y la medición del rendimiento. Dónde obtener Este identificador debe ser una clave única presente en las tablas de transacciones centrales de facturación o cargos dentro del Ciclo de Ingresos de Oracle Health. Consulte la documentación del sistema para identificar la clave principal para los eventos de cargos. Ejemplos BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Nombre de la Actividad ActivityName | El nombre del paso o evento específico que ocurrió dentro del proceso del ciclo de ingresos. | ||
| Descripción Este atributo registra el nombre de cada actividad realizada dentro del ciclo de vida de un evento de facturación. Los ejemplos incluyen 'Cargos Capturados', 'Reclamación Enviada al Pagador' y 'Pago Contabilizado'. Estas actividades forman los nodos del mapa de proceso descubierto. Analizar la secuencia y frecuencia de las actividades es el núcleo del Process Mining. Este atributo ayuda a identificar las rutas de proceso más comunes, descubrir desviaciones del procedimiento estándar y comprender el flujo operativo del ciclo de ingresos. Por qué es importante Define los pasos del proceso, permitiendo la visualización del mapa de procesos y el análisis de los patrones de Dónde obtener Típicamente derivado de registros de eventos, registros de cambios de estado o tablas de transacciones específicas asociadas con diferentes etapas del ciclo de ingresos en Oracle Health. Ejemplos Reclamación GeneradaRemesa RecibidaDenegación ApeladaCuenta Cerrada | |||
| Timestamp del Evento EventTimestamp | La fecha y hora precisas en que una actividad fue registrada en el sistema. | ||
| Descripción Este atributo proporciona la marca de tiempo para cada actividad, marcando el momento exacto en que ocurrió. Es esencial para comprender el momento y la secuencia de los eventos dentro del ciclo de ingresos para un evento de facturación específico. En el análisis, la Marca de Tiempo del Evento se utiliza para ordenar las actividades cronológicamente, calcular duraciones y tiempos de ciclo entre diferentes pasos, y realizar un análisis de cuellos de botella. Es la base para todas las métricas de Process Mining basadas en el tiempo, como la identificación de demoras entre 'Reclamación Enviada' y 'Remesa Recibida'. Por qué es importante Esta marca de tiempo es fundamental para ordenar eventos, calcular todas las métricas de rendimiento como los tiempos de ciclo y las duraciones, e identificar cuellos de botella del proceso. Dónde obtener Cada tabla de transacciones o Ejemplos 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Clase de Paciente PatientClass | La clasificación del encuentro del paciente, como Paciente Interno o Externo. | ||
| Descripción Este atributo categoriza el tipo de visita o encuentro del paciente que generó el cargo. Las clasificaciones comunes incluyen Paciente Interno, Paciente Externo, Emergencia y Paciente Recurrente. La clase de paciente a menudo dicta todo el proceso de facturación y presentación de reclamaciones. Diferentes clases de pacientes siguen rutas de proceso distintas y tienen diferentes requisitos de Cumplimiento. Analizar el proceso basándose en este atributo ayuda a comprender estas variaciones, adaptar las iniciativas de mejora y asegurar que se sigan los procedimientos correctos para cada clase. Por qué es importante Separa flujos de proceso distintos (p. ej., pacientes internos vs. externos) que presentan complejidades, plazos y requisitos de facturación diferentes. Dónde obtener Este es un campo estándar asociado con un encuentro de paciente o registro de admisión en Oracle Health. Ejemplos HospitalizaciónPaciente AmbulatorioUrgenteRecurrente | |||
| Código de Motivo de Denegación DenialReasonCode | Un código estandarizado que indica el motivo por el cual un pagador denegó una reclamación. | ||
| Descripción Cuando un pagador deniega una reclamación, proporciona un código de razón que explica la denegación, como 'Servicio no cubierto' o 'Reclamación duplicada'. Este atributo captura ese código y su descripción asociada. Analizar las razones de denegación es fundamental para mejorar el ciclo de ingresos. Permite a la organización identificar patrones comunes, como problemas con la codificación o la elegibilidad del paciente, e implementar acciones correctivas para prevenir futuras denegaciones. Esto impacta directamente la tasa de reclamaciones limpias y reduce el costo del retrabajo. Por qué es importante Proporciona la causa raíz de las denegaciones de reclamaciones, lo que permite mejoras específicas para aumentar la tasa de reclamaciones limpias y acelerar el cobro de ingresos. Dónde obtener Esta información se recibe en el aviso de remesa electrónico (archivo ANSI 835) del pagador y debe almacenarse en las tablas de reclamaciones o remesas en Oracle Health. Ejemplos CO-16: La reclamación/servicio carece de la información necesaria para la adjudicación.PR-96: Cargo(s) no cubierto(s).CO-18: Reclamación/servicio duplicado. | |||
| Departamento de Facturación BillingDepartment | El departamento o equipo funcional responsable de la actividad. | ||
| Descripción Este atributo especifica el departamento, como 'Captura de Cargos', 'Codificación' o 'Cobranzas', que realizó la actividad. Proporciona un contexto organizacional al flujo de proceso. Analizar el proceso desde una perspectiva departamental es esencial para comprender las transferencias entre equipos e identificar ineficiencias interfuncionales. Apoya el dashboard de 'Carga de Trabajo del Departamento de Facturación' al permitir la agregación de actividades y métricas de rendimiento a nivel departamental. Por qué es importante Asigna actividades a unidades organizativas, lo cual es clave para analizar las transferencias interdepartamentales, la carga de trabajo y el rendimiento del equipo. Dónde obtener Esta información podría almacenarse directamente con los datos del perfil de usuario en Oracle Health o derivarse en función del tipo de usuario o actividad. Ejemplos Acceso del PacienteCodificaciónFacturaciónCobranzas | |||
| Monto del Ajuste AdjustmentAmount | El valor monetario de cualquier ajuste realizado al saldo de la cuenta. | ||
| Descripción Este atributo captura el monto de cualquier ajuste financiero, como deducciones contractuales, cancelaciones o correcciones, aplicado al evento de facturación. Los ajustes reducen directamente los ingresos esperados de un cargo. El dashboard de 'Impacto de Ajustes de Cuenta' depende en gran medida de este atributo. Analizar los montos de ajuste y sus razones asociadas ayuda a identificar fuentes de fuga de ingresos, problemas con la gestión de contratos o problemas en el proceso inicial de captura de cargos. Es una métrica clave para la salud financiera. Por qué es importante Cuantifica la fuga de ingresos debido a cancelaciones o correcciones, ayudando a identificar y abordar las causas raíz de la erosión financiera. Dónde obtener Encontrado en las tablas de transacciones financieras que registran ajustes o castigos contra una cuenta de paciente. Ejemplos -50.25-120.0025.00 | |||
| Nombre del Pagador PayerName | El nombre de la compañía de seguros o pagador externo responsable del pago. | ||
| Descripción Este atributo identifica a 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 el análisis del ciclo de ingresos. Analizar el proceso por pagador puede revelar variaciones significativas en los tiempos de pago, tasas de denegación y tasas de éxito de apelaciones. Ayuda a identificar pagadores problemáticos que causan demoras o pérdida de ingresos y es esencial para gestionar eficazmente los contratos y las relaciones con los pagadores. Por qué es importante Permite la segmentación del proceso por pagador, revelando diferentes comportamientos, tasas de denegación y velocidades de pago, lo cual es crucial para el rendimiento financiero. Dónde obtener Esta información se almacena en los registros de facturación o seguro del paciente dentro del Ciclo de Ingresos de Oracle Health. Ejemplos AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Saldo Pendiente OutstandingBalance | El saldo impago restante para el evento de facturación en un momento dado. | ||
| Descripción Este atributo muestra el monto pendiente actual adeudado por un evento de facturación después de que se hayan aplicado todos los pagos y ajustes. Representa las cuentas por cobrar activas para ese cargo específico. Este es un atributo crítico para el dashboard de 'Antigüedad de Saldo Pendiente'. Analizar este valor a lo largo del tiempo ayuda a monitorear la velocidad del flujo de caja, evaluar la efectividad de los esfuerzos de cobranza y calcular KPIs financieros clave como los Días de Ventas Pendientes (DSO). Por qué es importante Realiza un seguimiento de las cuentas por cobrar actuales para cada caso, lo cual es esencial para gestionar el flujo de caja y analizar la efectividad de las cobranzas. Dónde obtener Este valor se calcula típicamente a partir de la suma de todas las transacciones financieras (cargos, pagos, ajustes) para un evento de facturación dado. Puede existir como un campo en una tabla de resumen de cuenta. Ejemplos 75.000.00550.80 | |||
| Usuario UserPerformingAction | El ID de usuario o el nombre de la persona que realizó la actividad. | ||
| Descripción Este atributo identifica al empleado o usuario del sistema automatizado responsable de ejecutar una actividad específica en el proceso. Es crucial para comprender la distribución de la carga de trabajo, el rendimiento de los recursos y la identificación de necesidades de capacitación. En el análisis, este atributo permite filtrar el mapa de procesos por usuario o equipo, comparar el rendimiento entre diferentes recursos y analizar la carga de trabajo para el dashboard de 'Carga de Trabajo del Departamento de Facturación'. Puede ayudar a identificar a los de mejor desempeño o a las personas que puedan requerir apoyo o capacitación adicional. Por qué es importante Vincula las actividades del proceso a usuarios o equipos específicos, lo que permite el análisis de la carga de trabajo, la comparación de rendimiento y la identificación de oportunidades de capacitación. Dónde obtener Los campos de ID de Usuario (p. ej., 'CREATED_BY', 'USER_ID') suelen estar presentes en las tablas de transacciones de los módulos de Oracle Health. Ejemplos j.doeasmithBillingBot_AUTOk.williams | |||
| ¿Es Retrabajo? IsRework | Un indicador que identifica actividades que representan retrabajo o esfuerzo repetido. | ||
| Descripción Este atributo calculado marca las actividades que indican una desviación del 'camino ideal' ('happy path') y constituyen retrabajo. Los ejemplos incluyen 'Reclamación Corregida Enviada' o 'Denegación Apelada', que no ocurrirían si el proceso se desarrollara perfectamente la primera vez. Identificar y cuantificar el retrabajo es un objetivo clave de Process Mining. Este indicador permite un filtrado y análisis sencillos de todos los ciclos de retrabajo, ayudando a medir la frecuencia, el costo y las causas de las ineficiencias del proceso. Es esencial para comprender el verdadero costo 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, destacando las ineficiencias del proceso y el costo de la mala calidad. Dónde obtener Este es un atributo derivado. Se calcula durante la transformación de datos aplicando lógica de negocio que marca nombres de actividades específicas como retrabajo. Ejemplos truefalse | |||
| Automatizado IsAutomated | Una bandera que indica si la actividad fue realizada por un sistema automatizado o un usuario humano. | ||
| Descripción Este atributo booleano distingue entre actividades ejecutadas por automatización de software, como Analizar este atributo ayuda a comprender el nivel de automatización en el proceso y su impacto en la eficiencia y las tasas de error. Puede utilizarse para comparar el rendimiento de las rutas automatizadas frente a las manuales e identificar oportunidades para una mayor automatización. Por qué es importante Diferencia entre actividades impulsadas por humanos y por sistemas, lo cual es crítico para analizar la efectividad de la automatización e identificar nuevas oportunidades de automatización. Dónde obtener Esto se deriva típicamente basándose en el atributo UserPerformingAction. Por ejemplo, las actividades realizadas por IDs de usuario como 'SYSTEM' o 'RPA_BOT' se marcan como automatizadas. Ejemplos truefalse | |||
| Claim ID ClaimId | El identificador único para 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 envía a un pagador para su reembolso. Un solo evento de facturación puede resultar en una o más reclamaciones a lo largo de su ciclo de vida, por ejemplo, si se necesita una corrección. Utilizar el ID de Reclamación permite rastrear un envío específico a un pagador y vincularlo directamente a la respuesta, como un pago o una denegación. Proporciona un nivel más granular de seguimiento dentro del proceso más amplio del ciclo de ingresos. Por qué es importante Proporciona un identificador específico para rastrear el recorrido de una reclamación con un pagador, lo cual es más granular que el Dónde obtener Este ID es generado por Oracle Health cuando se crea una reclamación y se almacena en la tabla principal de reclamaciones. Ejemplos CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| Hora Fin del Evento EventEndTime | La marca de tiempo que señala la finalización de una actividad, si está disponible. | ||
| Descripción Mientras StartTime marca el inicio de una actividad, EventEndTime marca su conclusión. No todas las actividades tienen una hora de finalización distinta, ya que muchas son eventos instantáneos. Sin embargo, para actividades que tienen una duración, como 'Denegación Apelada' que podría tardar en procesarse, este campo es muy útil. Este atributo permite un cálculo más preciso del tiempo de procesamiento para actividades individuales. Ayuda a diferenciar entre el tiempo de espera (tiempo entre actividades) y el tiempo de procesamiento (tiempo dedicado a una actividad). Por qué es importante Permite el cálculo directo de cuánto tiempo tarda una actividad en completarse, separando el tiempo de procesamiento del tiempo de espera. Dónde obtener Algunas tablas de transacciones en el Ciclo de Ingresos de Oracle Health pueden contener tanto una marca de tiempo de inicio como una de fin para tareas específicas de larga duración. Ejemplos 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| ID de Paciente PatientId | El identificador único para el paciente asociado con el evento de facturación. | ||
| Descripción Este atributo es el identificador único del paciente que recibió el servicio, a menudo conocido como Número de Expediente Médico (MRN). Vincula la transacción financiera a un individuo específico. Aunque no es el ID de caso para el proceso, el ID de Paciente es útil para agregar todos los eventos de facturación de un solo paciente y comprender su recorrido financiero completo. También permite la segmentación basada en la demografía o el historial del paciente si se une con los datos maestros del paciente. Por qué es importante Vincula Dónde obtener Este identificador es un elemento central del registro maestro de pacientes y estará presente en todas las tablas de transacciones relacionadas, como cargos, reclamaciones y pagos. Ejemplos MRN-1002345MRN-1002346MRN-1002347 | |||
| Monto del Cargo ChargeAmount | El valor monetario bruto del servicio o producto que se está facturando. | ||
| Descripción Este atributo representa el monto inicial, sin descuento, cargado por un servicio antes de que se apliquen ajustes, deducciones contractuales o pagos. Es el valor financiero inicial para el evento de facturación. Realizar un seguimiento del monto del cargo es crucial para el análisis financiero, como el cálculo del valor total de los servicios prestados y la comprensión del impacto financiero de los ajustes o cancelaciones posteriores. Sirve como línea base para medir la realización de ingresos. Por qué es importante Establece el valor financiero inicial del Dónde obtener Ubicado en las tablas de detalles de cargos o transacciones de cargos en Oracle Health. Ejemplos 150.001250.7585.50 | |||
| Razón de Disputa DisputeReason | La razón proporcionada por el cliente o paciente para impugnar una factura o cargo. | ||
| Descripción Este atributo captura la razón por la cual un paciente u otra parte responsable ha impugnado una factura. Las razones pueden incluir cargos incorrectos, servicios no prestados o problemas con el procesamiento del seguro. Esta información es esencial para el dashboard de 'Métricas de Resolución de Disputas de Facturas'. Comprender las razones más comunes 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 significativamente la tasa de disputa y la sobrecarga administrativa requerida para resolverlas. Por qué es importante Explica por qué se disputan las facturas, proporcionando una visión directa de los problemas de precisión o claridad de la facturación que deben corregirse. Dónde obtener Esto probablemente se almacena en un módulo de gestión de casos o de servicio al cliente dentro de Oracle Health, vinculado a la cuenta del paciente. Ejemplos Servicio Facturado IncorrectamenteCargo DuplicadoSeguro Facturado IncorrectamenteServicio No Prestado | |||
| Source System SourceSystem | El sistema del que se extrajeron los datos de events. | ||
| Descripción Este atributo identifica la aplicación o módulo de origen de los datos. Para este proceso, normalmente será 'Ciclo de Ingresos de Oracle Health', pero también podría especificar diferentes módulos dentro del sistema si los datos se integran desde múltiples lugares. Esta información es valiosa para la gobernanza de datos y la resolución de problemas. Ayuda a confirmar la procedencia de los datos y es importante en entornos donde múltiples sistemas contribuyen a un único proceso de principio a fin. Por qué es importante Proporciona contexto sobre el origen de los datos, lo cual es crucial para la validación de datos, la gobernanza y la comprensión de las variaciones del proceso que podrían depender del sistema. Dónde obtener Este es a menudo un valor estático añadido durante el proceso de extracción, transformación y carga de datos (ETL) para etiquetar el origen del conjunto de datos. Ejemplos OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| Tiempo de Procesamiento ProcessingTime | La duración del tiempo dedicado activamente a una actividad. | ||
| Descripción Este atributo mide el tiempo de procesamiento activo para un evento, calculado como la diferencia entre sus marcas de tiempo de inicio y fin. Ayuda a distinguir entre el tiempo dedicado activamente a una tarea y el tiempo de espera para el siguiente paso. Esta es una métrica crucial para el análisis de rendimiento, ya que aísla la eficiencia del recurso que realiza la tarea de las demoras sistémicas. Ayuda a responder preguntas sobre cuánto tiempo se tarda en codificar una reclamación o contabilizar un pago, independientemente del tiempo que el artículo estuvo en una cola de trabajo. Por qué es importante Mide la duración real del trabajo para una actividad, separándola del tiempo de inactividad o espera para proporcionar una visión más clara de la eficiencia de los recursos. Dónde obtener Esta es una métrica calculada, derivada de la resta de EventTimestamp de EventEndTime. Solo se puede calcular cuando ambos campos están disponibles. Ejemplos 300120045 | |||
| Última actualización de datos LastDataUpdate | La marca de tiempo que indica la última vez que se actualizaron o extrajeron los datos para 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 que se analizan, lo cual es importante para comprender la oportunidad de los conocimientos derivados del análisis de Process Mining. Los usuarios pueden verificar este atributo para confirmar que están viendo la información de proceso más reciente. Ayuda a gestionar las expectativas sobre la actualidad de los datos y es un componente clave de la gobernanza de datos y el aseguramiento de la calidad. Por qué es importante Indica la actualidad de los datos, asegurando que el análisis y las decisiones se basen en información actualizada. Dónde obtener Este es un campo de metadatos típicamente generado y poblado durante el proceso ETL que carga datos en la plataforma de Process Mining. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
Actividades de Gestión del Ciclo de Ingresos
| Actividad | Descripción | ||
|---|---|---|---|
| Cuenta Cerrada | La actividad final, que indica que el saldo de la cuenta es cero y no se espera ninguna actividad adicional. Esto se infiere a menudo cuando el saldo de la cuenta llega a cero. | ||
| Por qué es importante Marca la finalización exitosa del ciclo de ingresos. El tiempo para alcanzar este estado es una medida clave de la eficiencia general del proceso. Dónde obtener Esto se infiere típicamente identificando la primera vez que el saldo pendiente de la cuenta llega a cero y permanece en cero después de todos los pagos y ajustes. Capturar Calculado cuando el saldo de la cuenta es cero por primera vez después de que se contabilizan todos los cargos y pagos. Tipo de evento calculated | |||
| Encuentro de Paciente Creado | Marca la creación de una cuenta de paciente para una visita o servicio específico. Esto es típicamente un `event` explícito activado por el sistema de registro o una alimentación de Admisión/Alta/Transferencia (ADT). | ||
| Por qué es importante Sirve como punto de partida para todo el ciclo de ingresos de un Dónde obtener Obtenido de los registros del módulo de Registro de Pacientes o ADT. Busque eventos de creación de encuentro o la marca de tiempo más temprana asociada con el encuentro o número financiero. Capturar
Tipo de evento explicit | |||
| Pago Contabilizado | Representa la aplicación del pago recibido del pagador a los cargos correspondientes en la cuenta del paciente. Esta es una transacción financiera registrada por un usuario o un proceso automatizado. | ||
| Por qué es importante La eficiencia de la contabilización de pagos afecta la precisión de las cuentas por cobrar. Las demoras aquí pueden distorsionar el panorama financiero y retrasar la facturación secundaria. Dónde obtener Encontrado en las tablas de transacciones de pago. Cada contabilización de pago tendrá un ID de transacción único y un 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 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 pago. Analizar el tiempo desde el envío hasta el pago es clave para comprender el rendimiento del pagador y los Días de Ventas Pendientes (DSO). Dónde obtener Obtenido 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 'Enviado' en el historial de reclamaciones. Capturar
Tipo de evento explicit | |||
| Reclamación Generada | Marca el punto donde los cargos individuales se compilan en una reclamación de facturación formal, como un UB-04 o CMS-1500. Este es un `event` generado por el sistema que crea la factura inicial. | ||
| Por qué es importante Este es un hito importante que significa la preparación para facturar a un pagador. Es el punto final para medir el retraso interno de cargo a factura. Dónde obtener Un Capturar
Tipo de evento explicit | |||
| Actividad de Cobranza Iniciada | Indica que la cuenta del paciente ha sido trasladada a un proceso de cobranza debido a la falta de pago. Esto se captura típicamente mediante un cambio en la clase financiera o de estado de la cuenta. | ||
| Por qué es importante Este es un paso crítico para gestionar la deuda incobrable. Analizar qué conduce a esta etapa y su tasa de éxito es vital para la salud financiera. Dónde obtener Inferido de un cambio en el campo de estado de la cuenta a 'Cobranzas' o 'Deuda Incobrable'. Este cambio de estado debe tener un Capturar Inferido de un cambio de estado de cuenta a 'Cobranzas' o un estado similar. Tipo de evento inferred | |||
| Cargos Capturados | Representa la entrada de servicios o artículos facturables en la cuenta del paciente. Esto puede ocurrir automáticamente desde los sistemas clínicos o mediante la entrada manual por parte del personal. | ||
| Por qué es importante Esta actividad es fundamental para medir el 'retraso en la captura de cargos', el tiempo entre la prestación del servicio y el inicio de la facturación, lo que impacta directamente el flujo de caja y la integridad de los ingresos. Dónde obtener Capturado de las tablas de transacciones de cargos, identificado por el Capturar Entrada de registro de transacciones creada para cada nuevo cargo. Tipo de evento explicit | |||
| Cargos Codificados | Representa el proceso donde los codificadores médicos asignan códigos estandarizados, como CPT o ICD-10, a los cargos capturados. Esto a menudo se rastrea mediante un cambio de estado en el cargo o encuentro. | ||
| Por qué es importante Los retrasos en la codificación son un Dónde obtener A menudo inferido de un cambio de estado en el encuentro del paciente o en el lote de cargos, por ejemplo, de 'Sin Codificar' a 'Codificado'. Capturar Inferido de un cambio en el estado del encuentro o cargo a 'Codificado' o 'Listo para Facturar'. Tipo de evento inferred | |||
| Cuenta Ajustada | Representa un ajuste financiero realizado al saldo de la cuenta, como una asignación contractual, una cancelación o un descuento. Cada ajuste es una transacción financiera discreta. | ||
| Por qué es importante Los ajustes impactan directamente en los ingresos. Analizar su frecuencia, tipo y monto ayuda a identificar fugas de ingresos e imprecisiones en la facturación. Dónde obtener Encontrado en las tablas de transacciones financieras. Cada ajuste se registra como una partida separada con un código de transacción y un Capturar Se registra una transacción financiera con un código de ajuste específico. Tipo de evento explicit | |||
| Denegación Apelada | Una acción de usuario o del sistema que indica que se está apelando una reclamación denegada. Esto se captura típicamente 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 los esfuerzos de recuperación de ingresos. Dónde obtener Esto podría ser un evento explícito iniciado por el usuario o inferido de un cambio de estado en la reclamación, como 'Apelada' o 'En Revisión'. Capturar Un cambio de estado o Tipo de evento explicit | |||
| Denegación Recibida | Marca el `event` en el que el pagador ha rechazado una reclamación o partidas específicas, según lo indicado en el aviso de remesa. Este `event` a menudo se infiere de los códigos de denegación presentes en los datos de la remesa. | ||
| Por qué es importante El seguimiento de las denegaciones 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 obtener Inferido de los datos de la remesa (ERA/835). Cuando una reclamación o partida tiene un monto de denegación distinto de cero y un código de motivo de denegación correspondiente, se activa este Capturar Inferido de los datos de remesa que contienen códigos de motivo de denegación (CARCs/RARCs). Tipo de evento inferred | |||
| Estado de Cuenta del Paciente Enviado | Marca el `event` en el que se genera y envía al paciente una factura por la responsabilidad restante del paciente. Esta es una acción explícita registrada por el módulo de facturación del paciente. | ||
| Por qué es importante Esto inicia la porción de pago del paciente del ciclo de ingresos. El seguimiento de esto ayuda a analizar la eficacia de las cobranzas a pacientes. Dónde obtener Obtenido de los registros de facturación de pacientes o de correspondencia. El sistema debe registrar la fecha en que se generó o envió cada estado de cuenta. Capturar
Tipo de evento explicit | |||
| Reclamación Corregida Presentada | Representa el envío de una reclamación revisada o corregida al pagador, a menudo después de una denegación o una solicitud de más información. Esto se identifica mediante una nueva presentación 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 denegaciones. Una alta frecuencia indica problemas con la precisión inicial de la reclamación. Dónde obtener Capturado de los logs de envío de reclamaciones. Busque una nueva presentación para un encuentro existente, a menudo marcada con un código de reenvío o un número de iteración más alto. Capturar
Tipo de evento explicit | |||
| Remesa Recibida | Indica la recepción de un Aviso de Remesa Electrónica (ERA) o una Explicación de Beneficios (EOB) en papel del pagador. Este documento detalla qué cargos fueron pagados, denegados o ajustados. | ||
| Por qué es importante Esta es la primera respuesta del pagador y es crucial para comprender la velocidad de los pagos e identificar las tendencias de denegación tempranamente. Dónde obtener Registrado en el módulo de procesamiento de remesas. Busque el Capturar
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 del Ciclo de Ingresos de Oracle Health. Necesitará acceso a los esquemas que contienen datos de pacientes, encuentros, facturación y transacciones financieras. Esto suele requerir la aprobación de los equipos de seguridad de TI y administración de bases de datos.
- Identificar 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 tablas de su instancia de Oracle Health. Los nombres proporcionados en la consulta son marcadores de posición comunes y deben mapearse a su entorno específico.
- Instalar un Cliente SQL: Instale un cliente SQL compatible, como Oracle SQL Developer o DBeaver, en su estación de trabajo. Esta herramienta se utilizará para conectarse a la base de datos y ejecutar el script de extracción.
- Establecer Conexión a la Base de Datos: Configure una nueva conexión a la base de datos en su cliente SQL utilizando el host, puerto, nombre de servicio y credenciales proporcionados. Pruebe la conexión para asegurarse de que sea exitosa.
- Personalizar la Consulta SQL: Copie el script SQL proporcionado en una nueva ventana del editor de consultas. Localice los valores de los marcadores de posición, como
[START_DATE]y[END_DATE], y reemplácelos con el rango de fechas deseado para su análisis (por ejemplo, '2023-01-01'). Ajuste cualquier condición de filtro según sus necesidades analíticas específicas, como filtrar por una Clase de Paciente particular. - 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 horas en completarse, dependiendo del rango de fechas y el tamaño de su base de datos.
- Revisar los Resultados Iniciales: Una vez finalizada la consulta, revise las primeras cientos de filas en la cuadrícula de resultados de su cliente SQL. Verifique si hay errores obvios, como columnas totalmente nulas o formatos de datos incorrectos, para asegurarse de que el script se ejecutó correctamente.
- Exportar Datos a CSV: Exporte el conjunto de resultados completo a un archivo CSV. Utilice la codificación UTF-8 para evitar problemas de 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", "ActivityName").
- Preparar para la Carga: Antes de cargar a una herramienta de Process Mining, abra el archivo CSV para confirmar su integridad. Verifique que el formato del
timestampsea consistente y que los encabezados de columna coincidan exactamente con losatributosrequeridos. El archivo ya está listo para lacarga.
Configuración
- Rango de Fechas: La consulta utiliza los marcadores de posición
[START_DATE]y[END_DATE]. Es fundamental definir un rango de fechas específico y razonable para controlar el volumen de datos. Se recomienda un rango de 3 a 6 meses para un análisis inicial. - 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 acotar el alcance, por ejemplo,e.patient_class_code IN ('INPATIENT', 'OUTPATIENT')para centrarse en tipos de encuentros específicos. - Rendimiento: Consultar directamente una base de datos en un sistema de producción puede afectar el rendimiento. Se recomienda encarecidamente ejecutar esta extracción durante las horas de menor actividad 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 referenciadas en la consulta. Estas tablas incluyen tablas de encuentros, facturación, cargos, reclamaciones, remesas y transacciones financieras. - Mapeo de Tablas y Columnas: El script proporcionado utiliza nombres comunes y representativos para tablas y columnas. Debe validar y mapearlos con los nombres reales en el esquema de la base de datos de 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;