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 para el descubrimiento del proceso
- Instrucciones detalladas para extraer datos de R1 RCM
Atributos de la gestión del ciclo de ingresos
| Nombre | Descripción | ||
|---|---|---|---|
| Evento de facturación BillingEvent | Identificador único de un servicio o artículo facturable, que sirve como identificador principal del caso para hacer seguimiento a todo el ciclo de ingresos. | ||
| Descripción El ID del evento de facturación representa una instancia concreta de la prestación de un servicio o la entrega de un producto que genera un cargo. Es el hilo conductor que conecta todas las actividades relacionadas, desde la prestación inicial del servicio y el registro del cargo hasta el envío de la reclamación, el registro del pago y el cierre final de la cuenta. En Process Mining, analizar el ciclo de vida de cada evento de facturación permite obtener una visión completa del ciclo de ingresos de principio a fin. Se utiliza para seguir el recorrido de un cargo, identificar las rutas más habituales, medir los tiempos de ciclo entre hitos clave y comprender las variaciones que provocan demoras o pérdidas de ingresos. Por qué es importante Este identificador es esencial para agrupar todas las actividades relacionadas en un único caso y realizar un análisis completo y preciso del ciclo de ingresos de cada evento facturable. Dónde obtenerlo Es la clave principal que vincula distintas tablas relacionadas con las consultas de pacientes, los cargos, las reclamaciones y los pagos. Consulte la documentación de R1 RCM para identificar el campo específico, que suele corresponder a un identificador de consulta o de reclamación. Ejemplos BE-2023-0012345BE-2023-0054321BE-2024-0098765 | |||
| Fecha y hora del evento EventTime | Marca de tiempo que indica cuándo tuvo lugar una actividad o un evento específico. | ||
| Descripción La fecha y hora del evento indican con precisión cuándo se registró una actividad en el sistema. Esta información temporal es fundamental para analizar el proceso desde una perspectiva cronológica. En Process Mining, esta marca de tiempo permite ordenar los eventos cronológicamente y calcular la duración entre actividades, algo esencial para analizar el rendimiento. También permite calcular métricas clave, como el tiempo de ciclo, el tiempo de procesamiento y el tiempo de espera, necesarias para identificar cuellos de botella y medir la eficiencia. Por qué es importante Esta marca de tiempo es la base de todos los análisis relacionados con el tiempo, como el cálculo de los tiempos de ciclo, la identificación de cuellos de botella y el seguimiento del rendimiento del proceso frente a los SLA. Dónde obtenerlo En R1 RCM, suele aparecer como un campo «Creation Date», «Timestamp» o «Last Update Date» asociado a cada transacción o registro de cambio de estado. Ejemplos 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| Nombre de la actividad ActivityName | Nombre del evento de negocio o la tarea específica que tuvo lugar en un momento determinado del ciclo de ingresos. | ||
| Descripción Este atributo describe un paso o hito del proceso de gestión del ciclo de ingresos para un evento de facturación determinado. Las actividades representan el trabajo realizado, como «Cargos registrados», «Reclamación enviada» o «Pago registrado». Analizar la secuencia de actividades es fundamental en Process Mining. Permite descubrir el flujo real del proceso, detectar cuellos de botella en los que las actividades tardan demasiado en comenzar e identificar ciclos de retrabajo en los que se repiten pasos innecesariamente, como cuando a «Reclamación denegada» le sigue «Retrabajo de la denegación iniciado». Por qué es importante Define los pasos del proceso y permite visualizar el mapa del proceso, calcular los tiempos entre actividades e identificar desviaciones y retrabajos. Dónde obtenerlo Esta información suele obtenerse de registros de eventos, registros de cambios de estado o códigos de transacción de distintos módulos de R1 RCM. Puede ser necesario traducir los códigos técnicos a nombres comprensibles para el negocio. Ejemplos Cargos capturadosReclamación enviadaRespuesta del pagador recibidaPago contabilizadoCuenta cerrada | |||
| Sistema de origen SourceSystem | Sistema de registro del que se extrajeron los datos del evento. | ||
| Descripción Este atributo identifica la aplicación o el módulo de origen que generó los datos de un evento. En un entorno complejo como el sanitario, los datos pueden proceder de un sistema de historia clínica electrónica (EMR), un módulo de facturación, una cámara de compensación de reclamaciones o una plataforma de cobros. Conocer el sistema de origen es fundamental para validar los datos y analizar las variaciones del proceso que pueden depender de determinados sistemas. También ayuda a resolver incoherencias en los datos y a comprender el entorno tecnológico del proceso. Por qué es importante Identifica el origen de los datos, algo fundamental para la gobernanza de datos, la validación y la comprensión de cómo interactúan los distintos sistemas a lo largo del proceso. Dónde obtenerlo A menudo, es un valor estático que se añade durante la extracción de datos e identifica el sistema del que proceden, por ejemplo, «R1 RCM». Ejemplos R1 RCMCernerEpic | |||
| Última actualización de los datos LastDataUpdate | Marca de tiempo de la actualización o extracción más reciente de los datos del sistema de origen. | ||
| Descripción Este atributo indica cuándo se actualizaron por última vez los datos del análisis de Process Mining. Permite saber qué tan recientes son los datos analizados. Esta información es importante para los informes y los Dashboards, ya que indica a quienes los consultan qué tan actualizadas están las conclusiones sobre el proceso. También ayuda a establecer expectativas sobre la vigencia de los datos y a tomar decisiones teniendo en cuenta el periodo al que corresponden. Por qué es importante Aporta un contexto esencial sobre la vigencia de los datos y permite que analistas y partes interesadas sepan qué tan actualizadas están las conclusiones sobre el proceso. Dónde obtenerlo Esta marca de tiempo se genera durante el proceso de extracción, transformación y carga de datos (ETL) y suele aplicarse a todo el conjunto de datos. Ejemplos 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Código del motivo de denegación DenialReasonCode | Código estandarizado del pagador que explica por qué se denegó una reclamación. | ||
| Descripción Cuando un pagador deniega una reclamación, proporciona un código de motivo, como un CARC (Claim Adjustment Reason Code), para explicar la decisión. Estos códigos están estandarizados e indican problemas como «Servicio no cubierto» o «Reclamación duplicada». Este atributo es muy importante para gestionar las denegaciones. Analizar la frecuencia de los distintos códigos permite identificar y abordar las causas raíz de las denegaciones, ya sea que estén relacionadas con la elegibilidad del paciente, errores de codificación o falta de necesidad médica. Esto contribuye directamente a reducir el retrabajo y acelerar el flujo de efectivo. Por qué es importante Indica el motivo específico de las denegaciones de reclamaciones y permite analizar las causas raíz para reducir futuras denegaciones, disminuir el retrabajo y mejorar la tasa de pagos en el primer intento. Dónde obtenerlo Esta información se recibe del pagador en el aviso electrónico de pago (archivo ERA o 835) y se almacena en el módulo de gestión de reclamaciones de R1 RCM. Ejemplos CO-16: A la reclamación o al servicio le falta información necesaria para su evaluación.PR-97: La prestación de este servicio está incluida en el pago o la asignación correspondiente a otro servicio.CO-22: Es posible que otro pagador cubra esta atención, de acuerdo con la coordinación de beneficios.OA-18: Reclamación o servicio exactamente duplicado. | |||
| Departamento de facturación BillingDepartment | Departamento o equipo funcional responsable de realizar la actividad. | ||
| Descripción Este atributo especifica la unidad organizativa que realizó un paso del proceso, como «Registro de cargos», «Envío de reclamaciones» o «Gestión de denegaciones». Ayuda a comprender cómo se transfiere el trabajo entre los distintos equipos. Es fundamental para analizar el rendimiento de cada departamento e identificar cuellos de botella entre áreas. Al filtrar el mapa del proceso por departamento, las organizaciones pueden ver dónde se realizan las transferencias sin problemas y dónde se producen demoras, lo que facilita la asignación de recursos y la optimización de los procesos. Por qué es importante Permite analizar el rendimiento del proceso por unidad organizativa e identificar cuellos de botella específicos de cada equipo, limitaciones de recursos y buenas prácticas. Dónde obtenerlo Puede obtenerse del perfil de usuario en R1 RCM o almacenarse como «Department Code» en los datos de transacciones. Ejemplos Registro de cargosGestión de reclamacionesDenegaciones y recursosRegistro de pagos | |||
| Estado de la factura InvoiceStatus | Estado actual de la factura o reclamación en su ciclo de vida. | ||
| Descripción Este atributo indica el último estado conocido de un evento de facturación, como «Enviada», «Pagada», «Denegada» o «En gestión de cobro». Muestra en qué punto del proceso se encuentra una factura en un momento determinado. El estado de la factura es fundamental para elaborar informes de antigüedad de saldos y supervisar la situación de las cuentas por cobrar. En Process Mining, permite filtrar los casos estancados en un estado determinado o analizar los resultados de distintas variantes del proceso, por ejemplo, comparar las rutas de las reclamaciones «Pagadas» y «Denegadas». Por qué es importante Muestra el estado actual de cada caso, algo esencial para elaborar informes de antigüedad de saldos y analizar los resultados finales de las distintas rutas del proceso. Dónde obtenerlo En R1 RCM, suele ser un campo de estado del registro principal de la reclamación o la cuenta. Ejemplos Pendiente de envíoEnviada al pagadorDenegadaPagada en su totalidadEn gestión de cobro | |||
| Importe de la factura InvoiceAmount | Valor monetario total de los cargos incluidos en la factura o reclamación. | ||
| Descripción Este atributo representa el importe total facturado por los servicios prestados en un evento de facturación determinado. Refleja los ingresos que se esperan de la reclamación. Analizar el importe de la factura es fundamental para aplicar Process Mining a los procesos financieros. Permite priorizar las reclamaciones de mayor valor, comprender el impacto financiero de las demoras o denegaciones y segmentar el proceso según el importe. Por ejemplo, el análisis podría revelar que las reclamaciones que superan cierto importe siguen una ruta distinta y más manual. Por qué es importante Aporta contexto financiero al proceso, permite analizar cómo afectan las variaciones a los ingresos y ayuda a priorizar los casos de mayor valor para mejorarlos. Dónde obtenerlo Se encuentra en la tabla principal de encabezados de reclamaciones o facturas de R1 RCM, a menudo con un nombre como «TotalBilledAmount». Ejemplos 150.002500.7585.5012000.00 | |||
| Nombre del pagador PayerName | Nombre de la compañía de seguros, entidad gubernamental o paciente responsable del pago. | ||
| Descripción Este atributo identifica al pagador principal de la reclamación. Puede ser una aseguradora comercial, como Aetna; un pagador gubernamental, como Medicare; o el propio paciente, en el caso de los importes que paga directamente. Analizar el proceso por pagador es fundamental para gestionar el ciclo de ingresos. Puede revelar que algunos pagadores tienen más denegaciones, ciclos de pago más largos o requisitos de envío más complejos. Esta información permite adaptar los procesos y los recursos a las particularidades de cada pagador. Por qué es importante Permite segmentar el proceso por pagador e identificar demoras, patrones de denegación o comportamientos de pago específicos, algo fundamental para optimizar los ingresos. Dónde obtenerlo Se encuentra en la información demográfica o del seguro del paciente vinculada a la reclamación en R1 RCM. Ejemplos MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaPago directo del paciente | |||
| Usuario asignado AssignedUser | ID o nombre de la persona que realizó la actividad. | ||
| Descripción Este atributo identifica a la persona responsable de realizar una tarea específica del proceso. Puede ser quien preparó la reclamación, quien analizó y volvió a trabajar una denegación o quien registró un pago. Analizar los datos por usuario permite comprender cómo se distribuye la carga de trabajo, evaluar el rendimiento individual e identificar necesidades de formación. También puede mostrar qué personas trabajan con mayor eficiencia o cuáles están asociadas a más errores, lo que facilita la gestión y la mejora del proceso. Por qué es importante Permite analizar el rendimiento de los equipos y de cada persona, así como la distribución de la carga de trabajo, e identificar oportunidades de formación o desviaciones del proceso asociadas a usuarios específicos. Dónde obtenerlo En R1 RCM, suele aparecer como un campo «UserID», «Processor» o «UpdatedBy» en los registros de transacciones. Ejemplos jdoeasmithp.jonesBOT_RPA01 | |||
| Código del servicio ServiceCode | Código de facturación del servicio o procedimiento específico prestado, como un código CPT o HCPCS. | ||
| Descripción Los códigos de servicio, como los códigos CPT (Current Procedural Terminology), son códigos médicos estandarizados que se utilizan para informar a los pagadores sobre procedimientos y servicios médicos, quirúrgicos y de diagnóstico, y solicitar su reembolso. Analizar el proceso por código de servicio es esencial para identificar problemas de facturación relacionados con tipos de atención específicos. Permite detectar qué procedimientos se deniegan con mayor frecuencia, tienen ciclos de pago más largos o requieren más retrabajo, y así orientar las mejoras en las prácticas de codificación y facturación. Por qué es importante Permite analizar el proceso según el tipo de servicio prestado, algo clave para identificar patrones de denegación o demoras en los pagos asociados a procedimientos específicos. Dónde obtenerlo En R1 RCM, esta información se encuentra en el nivel de cada partida de cargo o reclamación. Ejemplos 992139928573560 | |||
| Es automatizada IsAutomated | Indicador que señala si la actividad la realizó un sistema automatizado o una persona. | ||
| Descripción Este atributo booleano distingue entre las tareas realizadas mediante automatización de software, como un bot de RPA que envía reclamaciones, y las tareas que realiza manualmente una persona. Analizar este atributo es clave para comprender el impacto y la eficacia de las iniciativas de automatización. Permite comparar la velocidad, el coste y la tasa de errores de los procesos automatizados y manuales, identificar nuevas oportunidades de automatización y medir el retorno de la inversión de los bots existentes. Por qué es importante Distingue las actividades realizadas por personas de las ejecutadas por sistemas, algo fundamental para medir el impacto de la automatización en la eficiencia, el coste y la calidad del proceso. Dónde obtenerlo Puede deducirse del campo «AssignedUser», si ciertos ID de usuario están reservados para bots, como «BOT_RPA01». Algunos sistemas también tienen un campo específico para indicar las transacciones automatizadas. Ejemplos truefalse | |||
| Es retrabajo IsRework | Indicador calculado que identifica las actividades que forman parte de un ciclo de retrabajo, como volver a enviar una reclamación denegada. | ||
| Descripción Este atributo es un indicador booleano que suele calcularse durante el análisis de Process Mining. Su valor es «true» si una actividad repite un paso anterior o forma parte de una secuencia que indica la corrección de un error, por ejemplo, cualquier actividad posterior a «Reclamación denegada». Identificar el retrabajo es una de las capacidades más útiles de Process Mining. Permite cuantificar el esfuerzo, el tiempo y los recursos desperdiciados en un proceso. Al señalar el retrabajo, las organizaciones pueden centrar las mejoras en prevenir los errores que lo provocan y lograr así aumentos importantes de eficiencia. Por qué es importante Ayuda a cuantificar la frecuencia y el impacto del retrabajo, como las denegaciones de reclamaciones, y permite orientar el análisis para reducir las ineficiencias y el esfuerzo desperdiciado. Dónde obtenerlo No es un campo del sistema de origen. La herramienta de Process Mining lo calcula a partir de la secuencia de actividades, por ejemplo, al detectar que «Reclamación enviada» aparece más de una vez en el mismo caso. Ejemplos truefalse | |||
| ID del paciente PatientId | Identificador único del paciente que recibió el servicio. | ||
| Descripción Este atributo es el ID único asignado a cada paciente en el sistema sanitario, conocido a menudo como número de historia clínica (MRN). Aunque la atención individual no es el objetivo del análisis, el ID del paciente permite detectar problemas de facturación recurrentes para una misma persona a lo largo del tiempo. También puede ayudar a segmentar el proceso según los datos demográficos o el historial del paciente, si se vincula con otros datos, y revelar problemas sistémicos que afectan a determinados grupos. Por qué es importante Permite analizar los eventos de facturación por paciente e identificar problemas o patrones recurrentes en distintas consultas. Dónde obtenerlo Este identificador forma parte de los datos demográficos básicos del paciente y está vinculado a cada consulta y reclamación en R1 RCM. Ejemplos MRN837262MRN937281MRN103847 | |||
| Importe del ajuste AdjustmentAmount | Valor monetario de un ajuste aplicado al saldo de la cuenta. | ||
| Descripción Este atributo registra el valor de los ajustes financieros aplicados a la cuenta de un paciente después de la facturación inicial. Los ajustes pueden ser positivos o negativos e incluir concesiones contractuales, castigos o correcciones. Hacer seguimiento a los importes de los ajustes es fundamental para comprender la integridad de los ingresos. Un nivel elevado de ajustes negativos puede indicar pérdidas de ingresos por problemas como un registro incorrecto de cargos o deudas incobrables. Analizar estos datos ayuda a identificar el impacto financiero de los errores de facturación y las ineficiencias en los cobros. Por qué es importante Cuantifica las pérdidas de ingresos y las correcciones financieras, y ayuda a determinar el impacto monetario de los errores de facturación, las obligaciones contractuales o las deudas incobrables. Dónde obtenerlo Se encuentra en los registros de transacciones relacionados con los ajustes de cuenta o el registro de pagos en R1 RCM. Ejemplos -50.2520.00-1200.00 | |||
| Motivo del ajuste AdjustmentReason | Motivo indicado para un ajuste financiero, como «Concesión contractual» o «Castigo por deuda incobrable». | ||
| Descripción Este atributo explica por qué se aplicó un ajuste financiero a una cuenta. Los motivos suelen ser códigos o descripciones estandarizados que clasifican el tipo de ajuste. Analizar los motivos de los ajustes ayuda a determinar las causas raíz de las pérdidas de ingresos. Por ejemplo, una frecuencia elevada de «Castigo de saldos pequeños» podría indicar que el proceso de cobro de importes pequeños es ineficiente, mientras que las «Concesiones contractuales» frecuentes suelen ser parte de las negociaciones con los pagadores. Este análisis sirve de apoyo al Dashboard de auditoría de ajustes de facturación y cumplimiento. Por qué es importante Explica los motivos de los ajustes de ingresos y ayuda a identificar las causas raíz de las pérdidas, como problemas contractuales, errores de facturación o fallos en los cobros. Dónde obtenerlo En R1 RCM, suele ser un campo de código o texto del mismo registro de transacción que AdjustmentAmount. Ejemplos Concesión contractualCastigo por deuda incobrableCastigo de saldo pequeñoCorrección de error de facturación | |||
| Resultado del cobro CollectionOutcome | Resultado final de las actividades de cobro de un saldo pendiente. | ||
| Descripción Este atributo describe el resultado de las gestiones para cobrar una cuenta vencida. Entre los posibles resultados están «Pagada en su totalidad», «Liquidada», «Clasificada como deuda incobrable» o «Sin resolver». Hacer seguimiento a los resultados de cobro es esencial para evaluar la eficacia del proceso. Analizar qué actividades conducen a cada resultado permite optimizar las estrategias de cobro, mejorar las tasas de recuperación y decidir con fundamento cuándo dejar de cobrar y castigar los saldos. Esto sirve de apoyo al Dashboard de rendimiento de las actividades de cobro. Por qué es importante Mide la eficacia del proceso de cobro mediante el seguimiento de la resolución final de las cuentas vencidas y ayuda a optimizar las estrategias de cobro. Dónde obtenerlo Probablemente sea un campo de estado de la cuenta del paciente o de un módulo específico de cobros en R1 RCM. Ejemplos Pagada en su totalidadLiquidada por un importe menorEnviada a una agencia externaCastigada como deuda incobrable | |||
| Tiempo de ciclo desde el servicio hasta el pago ServiceToPaymentCycleTime | Duración total calculada desde la prestación del servicio hasta el registro del pago final. | ||
| Descripción Esta métrica mide la duración total del ciclo de ingresos de un evento de facturación. Representa el tiempo que tarda una organización en convertir un servicio prestado en efectivo. Es un indicador clave de rendimiento (KPI) para la salud financiera. Analizar esta duración ayuda a identificar las principales oportunidades para acelerar el proceso. Al desglosar el tiempo de ciclo en sus componentes, como el tiempo hasta la facturación y el tiempo hasta el pago, las organizaciones pueden determinar dónde tienen más posibilidades de mejorar el flujo de efectivo. Por qué es importante Es un KPI clave de alto nivel que mide la eficiencia general del ciclo de conversión de efectivo y afecta directamente al flujo de efectivo de la organización. Dónde obtenerlo Esta métrica calculada corresponde a la diferencia entre la marca de tiempo de la actividad «Servicio prestado» y la de «Pago registrado» para un evento de facturación determinado. Ejemplos 35 días y 8 horas92 días y 4 horas15 días y 12 horas | |||
Actividades de la gestión del ciclo de ingresos
| Actividad | Descripción | ||
|---|---|---|---|
| Cargos capturados | Esta actividad indica el registro formal de todos los servicios, procedimientos y suministros facturables correspondientes a una consulta. Es un paso clave de entrada de datos que convierte las actividades clínicas en transacciones financieras. | ||
| Por qué es importante Marca el traspaso de las operaciones clínicas a las financieras. Es el punto de partida para medir los tiempos de ciclo de generación de facturas y reclamaciones, y ayuda a identificar retrasos en el registro de cargos. Dónde obtenerlo Se registra en el módulo de entrada de cargos de R1 RCM o se recibe mediante una interfaz desde una historia clínica electrónica. El evento suele quedar marcado en un registro de transacciones específico o con la fecha y hora de creación del registro del cargo. Capturar Se identifica por la fecha y hora de creación del registro de la transacción del cargo en la tabla de facturación. Tipo de evento explicit | |||
| Cuenta cerrada | El evento de facturación se ha resuelto por completo, el saldo es cero y la cuenta se cierra formalmente. Esto indica que el ciclo de ingresos de esta consulta ha finalizado correctamente. | ||
| Por qué es importante Este es el evento final de la ruta ideal del proceso. Medir el tiempo de ciclo de cierre de cuentas ayuda a garantizar que las tareas administrativas se completen con eficiencia y que los registros queden finalizados. Dónde obtenerlo Se deduce cuando el saldo de la cuenta llega a cero y se asigna el estado final «Cerrada» o «Pagada en su totalidad». La fecha y hora corresponden a la última transacción financiera que dejó el saldo en cero. Capturar Se deduce cuando el saldo de la cuenta llega a cero, se asigna el estado «Cerrada» y se registra la fecha y hora de la actividad final. Tipo de evento inferred | |||
| Pago contabilizado | El pago recibido se aplica oficialmente a la cuenta del paciente y reduce el saldo pendiente. Este es el paso final para conciliar un pago con los servicios facturados. | ||
| Por qué es importante Esta actividad marca el punto final para calcular los tiempos de ciclo entre la prestación del servicio y el pago, y de contabilización de pagos. Confirma que los ingresos se han reconocido y que las cuentas se han actualizado correctamente. Dónde obtenerlo Se registra como una transacción financiera explícita en el módulo de contabilidad de pacientes de R1 RCM. Cada contabilización incluye una fecha, un importe y un origen. Capturar Se registra como una transacción específica con una fecha de contabilización cuando una persona usuaria o un proceso automatizado aplica el pago. Tipo de evento explicit | |||
| Pago recibido | Se recibe un pago de un pagador o de un paciente. Este evento marca la recepción de los fondos, pero todavía no se han aplicado a una cuenta o línea de servicio específica. | ||
| Por qué es importante Representa una entrada de efectivo. El tiempo entre «Pago recibido» y «Pago contabilizado» es una métrica clave para comprender la eficiencia administrativa y los retrasos en la conciliación de efectivo. Dónde obtenerlo Se captura a partir de los archivos electrónicos de remesa de los pagadores o del procesamiento de pagos de pacientes. El evento corresponde a la fecha del depósito o a la fecha de recepción del archivo. Capturar Se registra a partir de la fecha efectiva del pago indicada en el archivo ERA o de la fecha de la transacción de un pago del paciente. Tipo de evento explicit | |||
| Reclamación enviada | La reclamación generada se envía electrónicamente al pagador responsable, como una compañía de seguros. Este es el primer contacto externo del proceso de facturación para obtener el reembolso. | ||
| Por qué es importante Es un hito clave que inicia el plazo para recibir el reembolso del pagador. Hacer un seguimiento permite supervisar los retrasos en los envíos y garantizar que se cumplan los plazos de presentación establecidos por los pagadores. Dónde obtenerlo Este evento se registra como una transacción explícita cuando la reclamación se transmite a una cámara de compensación. El sistema registra la fecha y hora del envío y los datos de confirmación. Capturar Se registra explícitamente como una transacción con la fecha y hora del envío cuando la reclamación se transmite a través de la cámara de compensación. Tipo de evento explicit | |||
| Servicio prestado | Indica que se ha completado para un paciente un servicio o procedimiento facturable. Este evento suele registrarse en un sistema clínico o de programación de citas y activa el ciclo de ingresos. | ||
| Por qué es importante Este es el punto de partida del KPI de tiempo de ciclo entre la prestación del servicio y el pago. Analizar el tiempo transcurrido desde este evento ayuda a identificar retrasos en las primeras etapas del ciclo de ingresos. Dónde obtenerlo Suele obtenerse de una historia clínica electrónica (EHR) o de un sistema de gestión de consultorios integrado con R1 RCM. A menudo se deduce de la fecha del servicio o de la fecha y hora de finalización del procedimiento en el registro del paciente. Capturar Se deduce de la fecha y hora de prestación del servicio asociadas a la consulta del paciente. Tipo de evento inferred | |||
| Ajuste de cuenta realizado | Se registra en la cuenta una transacción que no corresponde a un pago y modifica el saldo. Puede tratarse de ajustes contractuales basados en acuerdos con pagadores, cancelaciones de saldos pequeños o correcciones. | ||
| Por qué es importante Un volumen elevado de ajustes puede indicar problemas con las tarifas, la gestión de contratos o errores de facturación. Hacer un seguimiento de los ajustes es fundamental para analizar la integridad de los ingresos. Dónde obtenerlo Se registra como un tipo de transacción específico en el módulo de contabilidad de pacientes de R1 RCM. Cada ajuste tiene un código, un importe y una fecha de contabilización. Capturar Se registra como una transacción de ajuste independiente, identificable mediante un código de transacción único. Tipo de evento explicit | |||
| Cuenta clasificada como deuda incobrable | Se han agotado todas las gestiones de cobro y se considera que el saldo restante de la cuenta no se puede recuperar. El saldo se cancela como deuda incobrable, lo que representa una pérdida definitiva de ingresos. | ||
| Por qué es importante Este es un resultado negativo del proceso y representa una pérdida directa de ingresos. Analizar qué casos terminan como deuda incobrable puede revelar patrones de impago y oportunidades para mejorar los cobros. Dónde obtenerlo Suele registrarse como una transacción explícita en R1 RCM, cuando el saldo pendiente se transfiere a una categoría específica de deuda incobrable. El proceso suele iniciarlo una persona usuaria o una regla automatizada basada en la antigüedad de la deuda. Capturar Se registra como una transacción financiera específica para cancelar el saldo, a menudo asociada a su transferencia a una agencia de cobro externa. Tipo de evento explicit | |||
| Estado de cuenta del paciente generado | Después de que el seguro resuelve la reclamación, se genera un estado de cuenta para el paciente con el saldo restante que debe pagar. Puede corresponder a copagos, deducibles o servicios no cubiertos. | ||
| Por qué es importante Esta actividad inicia la parte del ciclo de ingresos correspondiente a los pagos de pacientes. Analizar cuándo y con qué frecuencia ocurre es importante para gestionar los cobros a pacientes y el flujo de caja. Dónde obtenerlo Suele registrarse como un evento cuando se ejecuta un proceso por lotes para crear e imprimir o enviar electrónicamente los estados de cuenta de los pacientes. R1 RCM registraría la fecha de generación del estado de cuenta. Capturar Se registra como una transacción cuando se ejecuta el proceso por lotes para generar los estados de cuenta de los pacientes. Tipo de evento explicit | |||
| Inicio de las actividades de cobro | La cuenta del paciente ha pasado a estar vencida y se inician gestiones proactivas de cobro. Estas pueden ir desde el envío automatizado de cartas de recordatorio hasta la asignación del caso a una persona especialista en cobros. | ||
| Por qué es importante Marca el inicio del costoso proceso de cobro. Analizar la eficacia y el tiempo de ciclo de estas actividades ayuda a optimizar las estrategias de recuperación de deudas incobrables. Dónde obtenerlo Es probable que este evento se registre o se deduzca de un cambio de estado cuando la cuenta se traslada a una cola de trabajo de cobros o se le asigna un código de estado de cobro en R1 RCM. Capturar Se deduce de un cambio de estado de la cuenta a «Cobros» o «Vencida». Tipo de evento inferred | |||
| Inicio del retrabajo de una denegación | Una persona usuaria o un flujo de trabajo automatizado inicia la investigación y resolución de una reclamación denegada. Esto puede implicar corregir la codificación, enviar documentación o apelar la decisión del pagador. | ||
| Por qué es importante Marca el inicio del costoso ciclo de retrabajo de las reclamaciones denegadas. Medir el tiempo que se dedica a esta etapa es clave para comprender la eficiencia del equipo de gestión de denegaciones. Dónde obtenerlo Este evento suele deducirse de un cambio de estado de la reclamación denegada a «Retrabajo en curso» o «En revisión» en una cola de trabajo o un módulo de gestión de denegaciones de R1 RCM. Capturar Se deduce de un cambio de estado en una cola de trabajo de gestión de denegaciones o de la primera acción de una persona usuaria sobre una reclamación denegada. Tipo de evento inferred | |||
| Reclamación creada | El sistema genera una reclamación formal de facturación a partir de los cargos capturados. Para ello, reúne los datos demográficos del paciente, la información del seguro y los códigos de servicio en un formato estandarizado. | ||
| Por qué es importante Es un hito interno clave antes del envío externo. Los retrasos en esta etapa pueden indicar problemas de codificación, validación de datos o configuración del sistema que ralentizan todo el proceso de facturación. Dónde obtenerlo Este es un evento interno del sistema R1 RCM. Probablemente se registra como un cambio de estado en la cuenta de facturación o mediante la fecha y hora de creación de la propia reclamación. Capturar Se deduce del cambio de estado a «Reclamación generada» o de la fecha y hora de creación del registro de la reclamación. Tipo de evento inferred | |||
| Reclamación denegada | El pagador se ha negado a pagar la reclamación, total o parcialmente. Se registra el motivo de la denegación y se inicia el proceso de retrabajo y apelación. | ||
| Por qué es importante Esta actividad pone de manifiesto la pérdida de ingresos y la ineficiencia del proceso. Analizar los motivos de las denegaciones es esencial para identificar sus causas y mejorar la tasa de aceptación de reclamaciones en el primer intento. Dónde obtenerlo No se trata de un evento independiente, sino de un estado que se deduce de los detalles de un archivo ERA procesado. Los códigos de denegación específicos de los datos de remesa provocan un cambio de estado en la reclamación. Capturar Se deduce de los códigos de denegación del archivo ERA procesado, que cambian el estado de la reclamación a «Denegada». Tipo de evento inferred | |||
| Respuesta del pagador recibida | El sistema recibe una respuesta del pagador sobre la reclamación enviada, a menudo en un archivo de aviso electrónico de pago (ERA). La respuesta detalla los importes pagados, denegados o ajustados. | ||
| Por qué es importante Este evento marca una bifurcación clave del proceso: determina si el siguiente paso será contabilizar el pago o gestionar una denegación. Analizarlo ayuda a comprender el comportamiento de los pagadores y la rapidez de los pagos. Dónde obtenerlo Se captura cuando R1 RCM procesa un archivo electrónico de remesa del pagador, como un archivo ANSI 835. El evento queda marcado con la fecha y hora de procesamiento del archivo. Capturar Se registra al recibir y procesar el archivo de aviso electrónico de pago (ERA/835). Tipo de evento explicit | |||
Guías de extracción
Pasos
- Inicie sesión en la plataforma R1 RCM con una cuenta de usuario que tenga permisos para acceder a los módulos de inteligencia empresarial o informes.
- Vaya a la sección de informes de la plataforma. Puede aparecer con el nombre "Business Intelligence", "Reporting Portal" o "Analytics".
- Busque la herramienta para crear un informe o una consulta personalizados. Esta le permite definir los campos de datos y la lógica específicos para la extracción.
- Como R1 RCM no proporciona un Registro de eventos unificado y listo para usar, debe crearlo combinando datos de distintas fuentes. La configuración de consulta proporcionada utiliza UNION ALL para combinar eventos de varios objetos de negocio en un único registro cronológico.
- Copie la consulta completa de la sección "Query" de este documento y péguela en el editor de consultas o la interfaz de configuración del informe personalizado.
- Configure los parámetros del informe, especialmente el intervalo de fechas. Defina los marcadores de posición
'{StartDate}'y'{EndDate}'de la consulta para establecer el período de extracción, por ejemplo, los últimos 6 meses. - Añada los filtros necesarios a la configuración del informe, como los de centros, departamentos o grupos de pagadores específicos, para delimitar los datos.
- Ejecute el informe. La consulta se ejecutará en la base de datos de R1 RCM y generará resultados según los parámetros especificados.
- Cuando termine de ejecutarse el informe, busque la opción para exportar los datos. Seleccione CSV (valores separados por comas) como formato de exportación, ya que es directamente compatible con ProcessMind.
- Descargue el archivo CSV generado y revíselo brevemente. Compruebe que los encabezados de columna coincidan con los atributos requeridos:
BillingEvent,ActivityName,EventTime,SourceSystemyLastDataUpdate. - Antes de cargar el archivo en ProcessMind, verifique que los formatos de fecha y hora de las columnas
EventTimeyLastDataUpdatesean coherentes.
Configuración
- Requisitos previos: Se necesita una cuenta de usuario con permisos suficientes para acceder al módulo de inteligencia empresarial de R1 RCM y crear informes personalizados.
- Tipo de informe: Use una consulta personalizada o un generador de informes avanzados que permita recuperar datos complejos y utilizar instrucciones UNION ALL para combinar distintos conjuntos de datos.
- Intervalo de fechas: Para controlar el rendimiento y el volumen de datos, es fundamental filtrar por un período específico. Para el análisis inicial, recomendamos empezar con un intervalo de 3 a 6 meses. Aplique el filtro de fecha al campo de marca de tiempo principal de cada actividad.
- Filtros clave: Además del intervalo de fechas, considere aplicar filtros por
Facility ID,Payer TypeoBilling Departmentpara centrar el análisis en áreas operativas específicas y reducir el tamaño de la exportación. - Formato de exportación: Seleccione siempre CSV como formato de salida. Así obtendrá un archivo estructurado y ordenado que las herramientas de Process Mining pueden procesar fácilmente.
- Programación: Si el módulo de informes de R1 RCM lo permite, programe la ejecución periódica del informe, por ejemplo, semanal o mensual, para actualizar los datos automáticamente y supervisarlos de forma continua.
Consulta de ejemplo sql
SELECT
c.ClaimID AS BillingEvent,
'Service Rendered' AS ActivityName,
c.ServiceDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ClinicianID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Rendered' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ServiceDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
c.ClaimID AS BillingEvent,
'Charges Captured' AS ActivityName,
c.ChargeEntryTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ChargeEntryUserID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Open' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ChargeEntryTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Created' AS ActivityName,
cl.CreationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.CreatedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Created' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.CreationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Submitted' AS ActivityName,
cl.SubmissionTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.SubmittedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Submitted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.SubmissionTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
era.ClaimID AS BillingEvent,
'Payer Adjudication Received' AS ActivityName,
era.ReceivedTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pa.InvoiceAmount AS InvoiceAmount,
era.PayerName AS PayerName,
'Adjudicated' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [RemittanceAdvice] era
JOIN [PatientAccounts] pa ON era.ClaimID = pa.BillingEvent
WHERE era.ReceivedTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
d.ClaimID AS BillingEvent,
'Claim Denied' AS ActivityName,
d.DenialTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Denied' AS InvoiceStatus,
d.ReasonCode AS DenialReasonCode
FROM [DenialsLog] d
JOIN [ClaimsData] cl ON d.ClaimID = cl.ClaimID
WHERE d.DenialTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
dr.ClaimID AS BillingEvent,
'Denial Rework Started' AS ActivityName,
dr.ReworkStartTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
dr.AssignedUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'In Rework' AS InvoiceStatus,
dr.OriginalDenialCode AS DenialReasonCode
FROM [DenialRework] dr
JOIN [ClaimsData] cl ON dr.ClaimID = cl.ClaimID
WHERE dr.ReworkStartTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ps.PatientAccountID AS BillingEvent,
'Patient Statement Generated' AS ActivityName,
ps.GenerationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ps.GeneratedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
ps.StatementBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Patient Billed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientStatements] ps
JOIN [PatientAccounts] pa ON ps.PatientAccountID = pa.BillingEvent
WHERE ps.GenerationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
p.AssociatedClaimID AS BillingEvent,
'Payment Received' AS ActivityName,
p.ReceiptTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
p.ProcessedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
p.PaymentAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Payment Pending' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentsLog] p
JOIN [PatientAccounts] pa ON p.AssociatedClaimID = pa.BillingEvent
WHERE p.ReceiptTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pt.ClaimID AS BillingEvent,
'Payment Posted' AS ActivityName,
pt.PostingTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pt.PostedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pt.PostedAmount AS InvoiceAmount,
pt.PayerName AS PayerName,
'Partially Paid' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentTransactions] pt
JOIN [PatientAccounts] pa ON pt.ClaimID = pa.BillingEvent
WHERE pt.PostingTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
a.ClaimID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
a.AdjustmentTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
a.AdjusterID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
a.AdjustmentAmount AS InvoiceAmount,
pa.PayerName AS PayerName,
'Adjusted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [Adjustments] a
JOIN [PatientAccounts] pa ON a.ClaimID = pa.BillingEvent
WHERE a.AdjustmentTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ca.PatientAccountID AS BillingEvent,
'Collection Activity Started' AS ActivityName,
ca.ActivityTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ca.AssignedAgentID AS AssignedUser,
'Collections' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'In Collections' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [CollectionsActivity] ca
JOIN [PatientAccounts] pa ON ca.PatientAccountID = pa.BillingEvent
WHERE ca.ActivityTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Placed in Bad Debt' AS ActivityName,
pa.BadDebtPlacementDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pa.BadDebtUserID AS AssignedUser,
'Finance' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Bad Debt' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.BadDebtPlacementDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Closed' AS ActivityName,
pa.ClosureDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
0 AS InvoiceAmount,
pa.PayerName AS PayerName,
'Closed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.ClosureDate BETWEEN '{StartDate}' AND '{EndDate}' AND pa.CurrentBalance = 0; ¿Todo listo para empezar?
Use este Template para agilizar la recopilación de datos y comenzar a optimizar la gestión del ciclo de ingresos. Le acompañaremos en cada paso.
Optimice ahora R1 RCM: mejore la eficiencia del ciclo de ingresos
Elimine cuellos de botella en el ciclo de ingresos, reduzca el tiempo de ciclo un 30 % y mejore el flujo de caja.
No se requiere tarjeta de crédito. Comience en unos minutos.