Votre modèle de données pour la gestion du cycle de revenus
Votre modèle de données pour la gestion du cycle de revenus
- Attributs recommandés à collecter
- Activités clés à suivre pour découvrir le processus
- Guide détaillé d’extraction pour R1 RCM
Attributs de la gestion du cycle de revenus
| Nom | Description | ||
|---|---|---|---|
| Date et heure de l’événement EventTime | Horodatage indiquant quand une activité ou un événement précis s’est produit. | ||
| Description La date et l’heure de l’événement indiquent précisément à quel moment une activité a été enregistrée dans le système. Cette information temporelle est essentielle pour analyser le processus dans le temps. Dans le Process Mining, cet horodatage sert à classer les événements par ordre chronologique et à calculer les durées entre les activités, ce qui est indispensable à l’analyse des performances. Il permet de calculer des indicateurs clés comme le temps de cycle, la durée de traitement et le temps d’attente, nécessaires pour repérer les goulots d’étranglement et mesurer l’efficacité. Pourquoi est-ce important ? Cet horodatage est à la base de toutes les analyses temporelles : calcul des temps de cycle, repérage des goulots d’étranglement et suivi des performances du processus par rapport aux SLA. Où trouver ces données Dans R1 RCM, ce champ figure généralement sous les noms « Date de création », « Horodatage » ou « Date de dernière mise à jour » dans les enregistrements de transaction ou de changement de statut. Exemples 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| Événement de facturation BillingEvent | Identifiant unique d’une prestation ou d’un article facturable, utilisé comme identifiant principal du dossier pour suivre l’ensemble du cycle de revenus. | ||
| Description L’identifiant de l’événement de facturation désigne une prestation ou une livraison de produit précise donnant lieu à des frais. Il constitue le fil conducteur qui relie toutes les activités associées, depuis la réalisation initiale de la prestation et la saisie des frais jusqu’à la soumission de la demande, la comptabilisation du paiement et la clôture du compte. Dans le Process Mining, l’analyse du cycle de vie de chaque événement de facturation donne une vue complète du cycle de revenus, de bout en bout. Elle permet de retracer le parcours d’un frais, de repérer les chemins les plus fréquents, de mesurer les temps de cycle entre les principales étapes et de comprendre les écarts qui entraînent des retards ou des pertes de revenus. Pourquoi est-ce important ? Cet identifiant est indispensable pour regrouper toutes les activités associées dans un même dossier et réaliser une analyse complète et précise du cycle de revenus pour chaque événement facturable. Où trouver ces données Il s’agit de la clé principale qui relie les différentes tables relatives aux épisodes de soins, aux frais, aux demandes de remboursement et aux paiements. Consultez la documentation de R1 RCM pour connaître le champ correspondant, souvent lié à un identifiant d’épisode de soins ou de demande. Exemples BE-2023-0012345BE-2023-0054321BE-2024-0098765 | |||
| Nom de l’activité ActivityName | Nom de l’événement métier ou de la tâche précise qui s’est produite à un moment donné du cycle de revenus. | ||
| Description Cet attribut décrit une étape ou un jalon du processus de gestion du cycle de revenus pour un événement de facturation donné. Les activités correspondent au travail effectué, par exemple « Frais saisis », « Demande soumise » ou « Paiement comptabilisé ». L’analyse de la séquence des activités est au cœur du Process Mining. Elle permet de découvrir le flux réel du processus, de repérer les goulots d’étranglement où le démarrage des activités prend trop de temps et de détecter les boucles de reprises, lorsque des activités sont répétées inutilement, par exemple « Demande refusée », puis « Reprise du traitement du refus ». Pourquoi est-ce important ? Il définit les étapes du processus et permet de visualiser la cartographie du processus, de calculer les temps de transition et de repérer les écarts et les reprises. Où trouver ces données Ces informations proviennent généralement des journaux d’événements, des enregistrements de changement de statut ou des codes de transaction des différents modules de R1 RCM. Il peut être nécessaire d’associer les codes techniques à des libellés compréhensibles par les équipes métier. Exemples Frais saisisDemande de remboursement transmiseRéponse du payeur reçuePaiement enregistréCompte clôturé | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage de la dernière actualisation ou extraction des données depuis le système source. | ||
| Description Cet attribut indique la date de la dernière mise à jour des données utilisées pour l’analyse du Process Mining. Il permet de savoir si les données analysées sont récentes. Cette information est utile pour les rapports et les Dashboards, car elle indique à l’utilisateur à quelle date remontent les analyses du processus. Elle permet de situer les données dans le temps et de prendre des décisions en connaissance de leur période de référence. Pourquoi est-ce important ? Il indique la date de mise à jour des données et permet aux analystes et aux parties prenantes de savoir si les analyses du processus reposent sur des informations récentes. Où trouver ces données Cet horodatage est généré lors du processus d’extraction, de transformation et de chargement des données (ETL) et s’applique généralement à l’ensemble du jeu de données. Exemples 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Système source SourceSystem | Système de référence à partir duquel les données d’événement ont été extraites. | ||
| Description Cet attribut identifie l’application ou le module source qui a généré les données d’un événement donné. Dans un environnement complexe comme celui des soins de santé, les données peuvent provenir d’un dossier médical électronique, d’un module de facturation, d’une plateforme de gestion des demandes ou d’un outil de recouvrement. Connaître le système source est important pour valider les données et analyser les variations du processus propres à certains systèmes. Cela aide à résoudre les incohérences et à comprendre l’environnement technologique dans lequel s’inscrit le processus. Pourquoi est-ce important ? Il indique l’origine des données, une information importante pour leur gouvernance et leur validation, ainsi que pour comprendre les interactions entre les systèmes tout au long du processus. Où trouver ces données Il s’agit souvent d’une valeur fixe ajoutée lors de l’extraction des données, qui indique le système d’origine, par exemple « R1 RCM ». Exemples R1 RCMCernerEpic | |||
| Code du motif de refus DenialReasonCode | Code normalisé fourni par l’organisme payeur pour expliquer le refus d’une demande. | ||
| Description Lorsqu’un organisme payeur refuse une demande, il fournit un code de motif, par exemple un CARC (Claim Adjustment Reason Code), pour expliquer sa décision. Ces codes normalisés signalent des problèmes tels que « Prestation non couverte » ou « Demande en double ». Cet attribut est essentiel à la gestion des refus. L’analyse de la fréquence des différents codes permet aux organisations de repérer et de traiter les causes profondes des refus, qu’elles soient liées à l’admissibilité du patient, à des erreurs de codage ou à l’absence de nécessité médicale. Elle contribue directement à réduire les reprises et à accélérer les encaissements. Pourquoi est-ce important ? Il précise le motif du refus d’une demande et permet d’en rechercher les causes afin de réduire les refus futurs, les reprises et les paiements nécessitant un nouveau traitement. Où trouver ces données Cette information est transmise par l’organisme payeur dans l’avis de paiement électronique (fichier ERA ou 835) et enregistrée dans le module de gestion des demandes de R1 RCM. Exemples CO-16 : la demande ou la prestation ne contient pas les informations nécessaires à son examen.PR-97 : la prestation est incluse dans le paiement ou le montant autorisé pour une autre prestation.CO-22 : selon les règles de coordination des prestations, cette prise en charge peut relever d’un autre organisme payeur.OA-18 : demande ou prestation strictement identique à une autre. | |||
| Montant de la facture InvoiceAmount | Montant total des frais figurant sur la facture ou la demande. | ||
| Description Cet attribut correspond au montant total facturé pour les prestations fournies lors d’un événement de facturation donné. Il représente les revenus attendus au titre de la demande. L’analyse du montant de la facture est importante pour le Process Mining financier. Elle permet de donner la priorité aux demandes de montant élevé, de comprendre les conséquences financières des retards ou des refus et de segmenter le processus selon les montants. Par exemple, l’analyse peut révéler que les demandes dépassant un certain montant suivent un parcours différent, avec davantage d’interventions manuelles. Pourquoi est-ce important ? Il apporte un éclairage financier sur le processus, permet d’analyser l’incidence des variations du processus sur les revenus et aide à donner la priorité aux dossiers de montant élevé. Où trouver ces données Dans R1 RCM, ce champ se trouve dans la table principale des demandes ou des factures. Il porte souvent le nom « TotalBilledAmount » ou un nom similaire. Exemples 150.002500.7585.5012000.00 | |||
| Nom de l’organisme payeur PayerName | Nom de la compagnie d’assurance, de l’organisme public ou du patient responsable du paiement. | ||
| Description Cet attribut identifie le principal organisme payeur de la demande. Il peut s’agir d’un assureur privé comme Aetna, d’un organisme public comme Medicare ou du patient lui-même pour les montants à sa charge. L’analyse du processus par organisme payeur est fondamentale pour la gestion du cycle de revenus. Elle peut révéler que certains organismes refusent davantage de demandes, règlent les paiements plus lentement ou imposent des exigences de soumission plus complexes. Ces analyses permettent à l’organisation d’adapter ses processus et ses ressources aux pratiques de chaque organisme payeur. Pourquoi est-ce important ? Il permet de segmenter le processus par organisme payeur afin de repérer les retards, les motifs de refus et les pratiques de paiement qui lui sont propres, et ainsi d’optimiser les revenus. Où trouver ces données Dans R1 RCM, cette information figure dans les données d’assurance ou les données démographiques du patient associées à la demande. Exemples MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaPaiement à la charge du patient | |||
| Service de facturation BillingDepartment | Service ou équipe fonctionnelle chargé d’effectuer l’activité. | ||
| Description Cet attribut désigne l’unité organisationnelle, par exemple « Saisie des frais », « Soumission des demandes » ou « Gestion des refus », qui a réalisé une étape du processus. Il aide à comprendre comment le travail est transmis d’une équipe à l’autre. Il est important pour analyser le débit de chaque service et repérer les goulots d’étranglement entre les fonctions. En filtrant la cartographie du processus par service, les organisations peuvent voir où les transmissions se déroulent sans difficulté et où des retards surviennent, afin de mieux répartir les ressources et d’optimiser les processus. Pourquoi est-ce important ? Cet attribut permet d’analyser les performances du processus par unité organisationnelle et de repérer les goulots d’étranglement propres à une équipe, les contraintes de ressources ou les bonnes pratiques. Où trouver ces données Cette information peut provenir du profil de l’utilisateur dans R1 RCM ou être enregistrée sous la forme d’un « Code de service » dans les données de transaction. Exemples Saisie des fraisGestion des demandes de remboursementRefus et recoursComptabilisation des paiements | |||
| Statut de la facture InvoiceStatus | Statut actuel de la facture ou de la demande dans son cycle de vie. | ||
| Description Cet attribut indique le dernier état connu d’un événement de facturation, par exemple « Soumis », « Payé », « Refusé » ou « En recouvrement ». Il donne un aperçu de l’étape à laquelle se trouve une facture dans le processus à un moment donné. Le statut de la facture est essentiel pour établir des rapports d’ancienneté et suivre l’état des comptes clients. Dans le Process Mining, il permet de filtrer les dossiers bloqués dans un état donné ou d’analyser les résultats des différentes variantes du processus, par exemple en comparant les parcours des demandes « Payées » et « Refusées ». Pourquoi est-ce important ? Il donne une vue de l’état actuel de chaque dossier, indispensable pour établir des rapports d’ancienneté et analyser les résultats des différents parcours du processus. Où trouver ces données Dans R1 RCM, il s’agit généralement d’un champ de statut dans l’enregistrement principal de la demande ou du compte. Exemples En attente de soumissionSoumis à l’organisme payeurRefuséEntièrement payéEn recouvrement | |||
| Utilisateur affecté AssignedUser | Identifiant ou nom de l’employé qui a effectué l’activité. | ||
| Description Cet attribut identifie la personne chargée d’exécuter une tâche précise dans le processus. Il peut s’agir de la personne qui a créé la demande, de l’analyste qui a repris le traitement d’un refus ou du spécialiste qui a comptabilisé un paiement. L’analyse par utilisateur permet de comprendre la répartition de la charge de travail, les performances individuelles et les besoins de formation. Elle peut mettre en évidence les utilisateurs les plus efficaces ou ceux dont les activités sont associées à davantage d’erreurs, afin de cibler les mesures de gestion et d’amélioration du processus. Pourquoi est-ce important ? Cet attribut permet d’analyser les performances des équipes et des personnes, ainsi que la répartition de la charge de travail. Il aide aussi à repérer les besoins de formation et les écarts de processus propres à certains utilisateurs. Où trouver ces données Dans R1 RCM, ce champ figure généralement dans les journaux de transaction sous les noms « UserID », « Processor » ou « UpdatedBy ». Exemples jdoeasmithp.jonesBOT_RPA01 | |||
| Automatisé IsAutomated | Indicateur précisant si l’activité a été réalisée par un système automatisé ou par une personne. | ||
| Description Cet attribut booléen distingue les tâches exécutées par une automatisation logicielle, comme un robot RPA chargé de soumettre les demandes, de celles effectuées manuellement par un employé. Son analyse est essentielle pour comprendre les effets des initiatives d’automatisation. Elle permet de comparer la vitesse, le coût et le taux d’erreur des processus automatisés et manuels, de repérer de nouvelles possibilités d’automatisation et de mesurer le retour sur investissement des robots déjà en place. Pourquoi est-ce important ? Il distingue les activités réalisées par une personne de celles exécutées par un système, ce qui permet de mesurer les effets de l’automatisation sur l’efficacité, le coût et la qualité du processus. Où trouver ces données Cette information peut être déduite du champ « AssignedUser », lorsque certains identifiants sont réservés aux robots, par exemple « BOT_RPA01 ». Certains systèmes disposent également d’un champ dédié pour signaler les transactions automatisées. Exemples truefalse | |||
| Code de prestation ServiceCode | Code de facturation de la prestation ou de l’acte réalisé, par exemple un code CPT ou HCPCS. | ||
| Description Les codes de prestation, comme les codes CPT (Current Procedural Terminology), sont des codes médicaux normalisés utilisés pour déclarer aux organismes payeurs les actes et prestations médicaux, chirurgicaux et diagnostiques en vue de leur remboursement. L’analyse du processus par code de prestation est essentielle pour repérer les problèmes de facturation liés à certains types de soins. Elle peut montrer quels actes font le plus souvent l’objet d’un refus, entraînent les temps de cycle de paiement les plus longs ou nécessitent le plus de reprises, afin de cibler les améliorations des pratiques de codage et de facturation. Pourquoi est-ce important ? Il permet d’analyser le processus selon le type de prestation réalisée, afin de repérer les motifs de refus ou les retards de paiement associés à certains actes. Où trouver ces données Dans R1 RCM, cette information figure au niveau de chaque ligne de frais ou de demande. Exemples 992139928573560 | |||
| Identifiant du patient PatientId | Identifiant unique du patient ayant reçu la prestation. | ||
| Description Cet attribut correspond à l’identifiant unique attribué à un patient dans le système de santé, souvent appelé numéro de dossier médical (MRN). Même si la prise en charge individuelle des patients n’est pas l’objet de l’analyse, l’identifiant du patient permet de repérer les problèmes de facturation récurrents pour une même personne au fil du temps. Associé à d’autres données sur les patients, il peut aussi servir à segmenter le processus selon les caractéristiques démographiques ou les antécédents et à mettre en évidence des problèmes systémiques touchant certains groupes. Pourquoi est-ce important ? Il permet d’analyser les événements de facturation à l’échelle du patient et de repérer les problèmes ou les tendances récurrents pour une même personne au fil de plusieurs épisodes de soins. Où trouver ces données Cet identifiant fait partie des données démographiques essentielles du patient associées à chaque épisode de soins et à chaque demande dans R1 RCM. Exemples MRN837262MRN937281MRN103847 | |||
| Montant de l’ajustement AdjustmentAmount | Valeur monétaire de l’ajustement apporté au solde du compte. | ||
| Description Cet attribut indique la valeur des ajustements financiers apportés au compte d’un patient après la facturation initiale. Ces ajustements peuvent être positifs ou négatifs et inclure des remises contractuelles, des radiations ou des corrections. Le suivi des montants ajustés est essentiel pour comprendre l’intégrité des revenus. Des ajustements négatifs importants peuvent signaler des pertes de revenus dues, par exemple, à une saisie incorrecte des frais ou à des créances irrécouvrables. L’analyse de ces données permet de mesurer les conséquences financières des erreurs de facturation et des inefficacités du recouvrement. Pourquoi est-ce important ? Il quantifie les pertes de revenus et les corrections financières, et aide à mesurer les conséquences des erreurs de facturation, des obligations contractuelles ou des créances irrécouvrables. Où trouver ces données Dans R1 RCM, cette information figure dans les journaux de transaction relatifs aux ajustements de compte ou à la comptabilisation des paiements. Exemples -50.2520.00-1200.00 | |||
| Motif de l’ajustement AdjustmentReason | Motif indiqué pour un ajustement financier, par exemple « Remise contractuelle » ou « Créance irrécouvrable passée en perte ». | ||
| Description Cet attribut précise la raison d’un ajustement financier apporté à un compte. Les motifs sont souvent des codes ou des descriptions normalisés qui classent les différents types d’ajustement. L’analyse des motifs d’ajustement aide à déterminer les causes profondes des pertes de revenus. Par exemple, des radiations fréquentes de « petits soldes » peuvent signaler un processus de recouvrement inefficace pour les petits montants, tandis que les « remises contractuelles » fréquentes sont généralement liées aux accords conclus avec les organismes payeurs. Cette analyse alimente le Dashboard d’audit des ajustements de facturation et de conformité. Pourquoi est-ce important ? Il explique les raisons des ajustements de revenus et aide à repérer les causes profondes des pertes, comme les problèmes contractuels, les erreurs de facturation ou les échecs de recouvrement. Où trouver ces données Dans R1 RCM, il s’agit généralement d’un code ou d’un champ texte dans le même enregistrement de transaction que AdjustmentAmount. Exemples Remise contractuelleCréance irrécouvrable passée en perteRadiation d’un petit soldeCorrection d’une erreur de facturation | |||
| Reprise IsRework | Indicateur calculé qui repère les activités faisant partie d’une boucle de reprises, comme la nouvelle soumission d’une demande refusée. | ||
| Description Cet attribut booléen est généralement calculé lors de l’analyse du Process Mining. Il prend la valeur « vrai » lorsqu’une activité répète une étape précédente ou s’inscrit dans une séquence indiquant la correction d’une erreur, par exemple toute activité qui suit « Demande refusée ». Le repérage des reprises est l’une des principales possibilités offertes par le Process Mining. Il permet de quantifier le temps, les efforts et les ressources consacrés inutilement au processus. En repérant les reprises, les organisations peuvent concentrer leurs efforts d’amélioration sur la prévention des erreurs qui les provoquent et ainsi gagner en efficacité. Pourquoi est-ce important ? Il aide à quantifier la fréquence et les conséquences des reprises, notamment après un refus de demande, afin de cibler les analyses et de réduire les inefficacités et les efforts inutiles. Où trouver ces données Ce champ n’existe pas dans le système source. L’outil de Process Mining le calcule à partir de la séquence des activités, par exemple en repérant qu’une activité « Demande soumise » se produit plusieurs fois pour un même dossier. Exemples truefalse | |||
| Résultat du recouvrement CollectionOutcome | Résultat final des démarches de recouvrement d’un solde impayé. | ||
| Description Cet attribut décrit le résultat des démarches visant à obtenir le paiement d’un compte en retard. Les résultats possibles comprennent « Entièrement payé », « Réglé », « Passé en créance irrécouvrable » ou « Non résolu ». Le suivi des résultats du recouvrement est essentiel pour évaluer l’efficacité du processus. En analysant les activités qui mènent à chaque résultat, les organisations peuvent optimiser leurs stratégies de recouvrement, améliorer les taux de récupération et décider en connaissance de cause quand interrompre les démarches et radier les soldes. Ces informations alimentent le Dashboard de suivi des performances des activités de recouvrement. Pourquoi est-ce important ? Il mesure l’efficacité du recouvrement en suivant le règlement final des comptes en retard et aide à optimiser les stratégies de recouvrement. Où trouver ces données Il s’agit probablement d’un champ de statut dans le compte du patient ou dans un module dédié au recouvrement de R1 RCM. Exemples Entièrement payéRéglé pour un montant inférieurTransmis à une agence externePassé en créance irrécouvrable | |||
| Temps de cycle entre la prestation et le paiement ServiceToPaymentCycleTime | Durée totale calculée entre la réalisation d’une prestation et la comptabilisation du paiement final. | ||
| Description Cette métrique mesure la durée totale du cycle de revenus pour un événement de facturation. Elle correspond au temps nécessaire à une organisation pour convertir une prestation fournie en encaissement. Il s’agit d’un indicateur clé de la santé financière. L’analyse de cette durée aide à repérer les principaux leviers d’accélération du processus. En décomposant le temps de cycle en différentes étapes, comme le délai de facturation et le délai de paiement, les organisations peuvent déterminer où se trouvent les meilleures possibilités d’améliorer leur trésorerie. Pourquoi est-ce important ? Cet indicateur clé de haut niveau mesure l’efficacité globale du cycle de conversion en trésorerie et a une incidence directe sur la trésorerie de l’organisation. Où trouver ces données Cette métrique est calculée à partir de l’écart entre l’horodatage de l’activité « Prestation réalisée » et celui de l’activité « Paiement comptabilisé » pour un événement de facturation donné. Exemples 35 jours et 8 heures92 jours et 4 heures15 jours et 12 heures | |||
Activités de gestion du cycle de revenus
| Activité | Description | ||
|---|---|---|---|
| Compte clôturé | L’événement de facturation est entièrement résolu, le solde est nul et le compte est officiellement clôturé. Cela marque la fin du cycle de revenus pour cette consultation. | ||
| Pourquoi est-ce important ? Il s’agit de l’événement de fin du parcours nominal. La mesure du temps de cycle de clôture des comptes permet de vérifier que les tâches administratives sont effectuées efficacement et que les dossiers sont finalisés. Où trouver ces données Cet événement est déduit lorsque le solde du compte atteint zéro et que le statut final « Closed » ou « Paid in Full » est appliqué. L’horodatage correspond à la dernière transaction financière ayant ramené le solde à zéro. Données à recueillir Déduit lorsque le solde du compte atteint zéro, que le statut « Closed » est appliqué et qu’un horodatage de la dernière activité est disponible. Type d’événement inferred | |||
| Demande de remboursement transmise | La demande de remboursement générée est transmise par voie électronique au payeur concerné, par exemple une compagnie d’assurance. Il s’agit du premier échange externe du processus de facturation visant à obtenir le remboursement. | ||
| Pourquoi est-ce important ? Cette étape importante marque le début du délai de remboursement par le payeur. Son suivi permet de surveiller les retards de transmission et de respecter les délais de dépôt imposés par les payeurs. Où trouver ces données Cet événement est enregistré comme une transaction explicite lorsque la demande de remboursement est transmise à un centre de traitement. Le système consigne l’horodatage de l’envoi et les détails de confirmation. Données à recueillir Enregistré explicitement comme une transaction avec un horodatage de transmission lorsque la demande de remboursement est envoyée par l’intermédiaire du centre de traitement. Type d’événement explicit | |||
| Frais saisis | Cette activité correspond à l’enregistrement officiel de toutes les prestations, interventions et fournitures facturables associées à une consultation. Cette étape de saisie transforme les actes cliniques en transactions financières. | ||
| Pourquoi est-ce important ? Elle marque le passage des opérations cliniques aux opérations financières. C’est le point de départ pour mesurer les temps de cycle de génération des factures et des demandes de remboursement, et pour repérer les retards de saisie des frais. Où trouver ces données L’événement est enregistré dans le module de saisie des frais de R1 RCM ou reçu par une interface depuis un dossier médical informatisé. Il est généralement signalé par une transaction précise dans le journal ou par l’horodatage de création de l’enregistrement des frais. Données à recueillir Repéré grâce à l’horodatage de création de la transaction de frais dans la table de facturation. Type d’événement explicit | |||
| Paiement enregistré | Le paiement reçu est officiellement affecté au compte du patient, ce qui réduit le solde impayé. Cette étape finale permet de rapprocher le paiement des prestations facturées. | ||
| Pourquoi est-ce important ? Cette activité marque la fin du temps de cycle entre la prestation et le paiement, ainsi que du temps de cycle d’enregistrement du paiement. Elle confirme que les revenus sont comptabilisés et que les comptes sont à jour. Où trouver ces données Il est enregistré comme une transaction financière explicite dans le module de comptabilité des patients de R1 RCM. Chaque enregistrement comprend une date, un montant et une source. Données à recueillir Enregistré comme une transaction précise, avec une date d’enregistrement, lorsqu’un utilisateur ou un processus automatisé affecte le paiement. Type d’événement explicit | |||
| Paiement reçu | Un paiement est reçu d’un payeur ou d’un patient. Cet événement marque la réception des fonds, qui ne sont pas encore affectés au compte ou aux prestations concernés. | ||
| Pourquoi est-ce important ? Marque une entrée de trésorerie. Le délai entre « Payment Received » et « Payment Posted » est un indicateur important pour évaluer l’efficacité des opérations administratives et les retards de rapprochement des paiements. Où trouver ces données L’événement est enregistré à partir des fichiers de paiement électronique des payeurs ou du traitement des paiements des patients. Il correspond à la date du dépôt ou de réception du fichier. Données à recueillir Enregistré à partir de la date d’effet du paiement indiquée dans le fichier ERA ou de la date de transaction d’un paiement effectué par un patient. Type d’événement explicit | |||
| Prestation effectuée | Indique qu’une prestation ou une intervention facturable pour un patient est terminée. Cet événement est souvent enregistré dans un système clinique ou de planification et déclenche le cycle de revenus. | ||
| Pourquoi est-ce important ? Cet événement marque le début du temps de cycle entre la prestation et le paiement. L’analyse du délai à partir de ce point permet de repérer les retards en amont du cycle de revenus. Où trouver ces données Ces données proviennent généralement d’un dossier médical informatisé (DMI) ou d’un système de gestion de cabinet intégré à R1 RCM. Elles sont souvent déduites de l’horodatage « Service Date » ou « Procedure Completed » dans le dossier du patient. Données à recueillir Déduit de l’horodatage « Date of Service » associé à la consultation du patient. Type d’événement inferred | |||
| Ajustement du compte effectué | Une transaction autre qu’un paiement est enregistrée sur le compte pour en modifier le solde. Il peut s’agir d’ajustements contractuels prévus par les accords avec les payeurs, de l’abandon de petits soldes ou de corrections. | ||
| Pourquoi est-ce important ? Un volume élevé d’ajustements peut révéler des problèmes de barèmes tarifaires, de gestion des contrats ou des erreurs de facturation. Le suivi des ajustements est essentiel pour analyser l’intégrité des revenus. Où trouver ces données Enregistré comme un type de transaction précis dans le module de comptabilité des patients de R1 RCM. Chaque ajustement comporte un code, un montant et une date d’enregistrement. Données à recueillir Enregistré comme une transaction d’ajustement distincte, identifiable par un code de transaction unique. Type d’événement explicit | |||
| Compte passé en créance irrécouvrable | Toutes les démarches de recouvrement ont échoué et le solde restant est considéré comme irrécouvrable. Il est passé en perte, ce qui correspond à une perte définitive de revenus. | ||
| Pourquoi est-ce important ? Il s’agit d’une issue défavorable du processus et d’une perte directe de revenus. L’analyse des cas qui aboutissent à une créance irrécouvrable peut révéler des tendances de non-paiement et des possibilités d’améliorer le recouvrement. Où trouver ces données Il s’agit généralement d’une transaction explicite dans R1 RCM, qui transfère le solde impayé vers une catégorie de créances irrécouvrables. Ce transfert est souvent déclenché par un utilisateur ou par des règles automatisées fondées sur l’ancienneté de la créance. Données à recueillir Enregistré comme une transaction financière précise pour passer le solde en perte, souvent à la suite d’un transfert à une agence de recouvrement externe. Type d’événement explicit | |||
| Début du recouvrement | Le compte du patient est en retard de paiement et des démarches de recouvrement sont engagées. Celles-ci peuvent aller de l’envoi automatique de lettres de rappel à la prise en charge du dossier par un spécialiste du recouvrement. | ||
| Pourquoi est-ce important ? Marque le début d’un processus de recouvrement coûteux. L’analyse de l’efficacité et du temps de cycle de ces activités aide à optimiser les stratégies de recouvrement des créances irrécouvrables. Où trouver ces données Cet événement est probablement enregistré ou déduit d’un changement de statut lorsque le compte est transféré dans une file de travail de recouvrement ou reçoit un code de statut correspondant dans R1 RCM. Données à recueillir Déduit du passage du compte au statut « Collections » ou « Delinquent ». Type d’événement inferred | |||
| Début du traitement d’une demande refusée | Un utilisateur ou un flux de travail automatisé commence à examiner et à traiter une demande de remboursement refusée. Il peut s’agir de corriger le codage, de transmettre des documents ou de contester la décision du payeur. | ||
| Pourquoi est-ce important ? Marque le début du cycle de reprises coûteux associé aux demandes refusées. La mesure du temps passé à cette étape est essentielle pour évaluer l’efficacité de l’équipe chargée de traiter les refus. Où trouver ces données Cet événement est souvent déduit du passage de la demande refusée au statut « Rework in Progress » ou « Under Review » dans une file de travail ou un module de gestion des refus de R1 RCM. Données à recueillir Déduit d’un changement de statut dans une file de travail de gestion des refus ou de la première intervention d’un utilisateur sur une demande refusée. Type d’événement inferred | |||
| Demande de remboursement créée | Une demande de remboursement est générée dans le système à partir des frais saisis. Elle rassemble les données démographiques du patient, les informations d’assurance et les codes de prestation dans un format standardisé. | ||
| Pourquoi est-ce important ? Cette étape interne importante précède l’envoi à l’organisme payeur. Les retards à ce stade peuvent révéler des problèmes de codage, de validation des données ou de configuration du système qui ralentissent l’ensemble du processus de facturation. Où trouver ces données Il s’agit d’un événement interne au système R1 RCM. Il est probablement enregistré comme un changement de statut du compte de facturation ou repéré grâce à l’horodatage de création de la demande de remboursement. Données à recueillir Déduit du passage au statut « Claim Generated » ou de l’horodatage de création de l’enregistrement de la demande de remboursement. Type d’événement inferred | |||
| Demande de remboursement refusée | Le payeur refuse de rembourser tout ou partie de la demande. Le motif du refus est enregistré et déclenche un processus de reprise et de recours. | ||
| Pourquoi est-ce important ? Cette activité révèle une perte de revenus et une inefficacité du processus. L’analyse des motifs de refus est essentielle pour en repérer les causes profondes et améliorer le taux d’acceptation dès la première soumission. Où trouver ces données Il ne s’agit pas d’un événement distinct, mais d’un statut déduit des informations contenues dans un fichier ERA traité. Certains codes de refus présents dans les données de paiement entraînent un changement de statut de la demande. Données à recueillir Déduit des codes de refus présents dans le fichier ERA traité, qui font passer la demande au statut « Denied ». Type d’événement inferred | |||
| Relevé de compte du patient généré | Après le traitement de la demande par l’assurance, un relevé est créé pour indiquer au patient le solde restant à sa charge. Il peut s’agir de participations forfaitaires, de franchises ou de prestations non couvertes. | ||
| Pourquoi est-ce important ? Cette activité marque le début de la partie du cycle de revenus consacrée aux paiements des patients. L’analyse de son calendrier et de sa fréquence est importante pour gérer le recouvrement auprès des patients et la trésorerie. Où trouver ces données L’événement est généralement enregistré lors de l’exécution d’un traitement par lots qui génère et imprime les relevés des patients ou les leur envoie par voie électronique. R1 RCM consigne la date de génération du relevé. Données à recueillir Enregistré comme une transaction lors de l’exécution du traitement par lots qui génère les relevés des patients. Type d’événement explicit | |||
| Réponse du payeur reçue | Le système reçoit une réponse du payeur au sujet de la demande de remboursement transmise, souvent sous la forme d’un fichier d’avis de paiement électronique (ERA). Cette réponse précise les montants payés, refusés ou ajustés. | ||
| Pourquoi est-ce important ? Cet événement marque une bifurcation importante du processus : l’étape suivante concerne soit l’enregistrement du paiement, soit le traitement du refus. Son analyse aide à comprendre le comportement des payeurs et les délais de paiement. Où trouver ces données L’événement est enregistré lorsque R1 RCM traite un fichier de paiement électronique transmis par le payeur, par exemple un fichier ANSI 835. Il est marqué par l’horodatage de traitement du fichier. Données à recueillir Enregistré lors de la réception et du traitement du fichier d’avis de paiement électronique (ERA/835). Type d’événement explicit | |||
Guides d’extraction
Étapes
- Connectez-vous à la plateforme R1 RCM avec un compte utilisateur autorisé à accéder aux modules de Business Intelligence ou de rapports.
- Accédez à la section des rapports de la plateforme. Elle peut s’appeler « Business Intelligence », « Reporting Portal » ou « Analytics ».
- Repérez l’outil permettant de créer un rapport ou une requête personnalisés. Il vous permet de définir les champs de données et la logique d’extraction.
- R1 RCM ne fournit pas de journal d’événements unifié prêt à l’emploi. Vous devez donc en créer un en combinant des données provenant de différentes sources. La configuration de requête fournie utilise UNION ALL pour regrouper les événements de différents objets métier dans un journal chronologique unique.
- Copiez la requête complète indiquée dans la section « Query » de ce document et collez-la dans l’éditeur de requêtes ou l’interface de configuration du rapport personnalisé.
- Configurez les paramètres du rapport, en particulier la période. Renseignez les espaces réservés
'{StartDate}'et'{EndDate}'dans la requête pour définir la période d’extraction, par exemple les six derniers mois. - Ajoutez les filtres nécessaires à la configuration du rapport, par exemple pour sélectionner certains établissements, services ou groupes de payeurs et limiter le périmètre des données.
- Exécutez le rapport. La requête sera lancée sur la base de données R1 RCM et produira les résultats correspondant aux paramètres définis.
- Une fois le rapport généré, choisissez l’option d’exportation. Sélectionnez CSV (Comma Separated Values), un format directement compatible avec ProcessMind.
- Téléchargez le fichier CSV généré et ouvrez-le pour effectuer une vérification rapide. Assurez-vous que les en-têtes de colonnes correspondent aux attributs requis :
BillingEvent,ActivityName,EventTime,SourceSystemetLastDataUpdate. - Vérifiez que les formats de date et d’heure des colonnes
EventTimeetLastDataUpdatesont cohérents avant d’importer le fichier dans ProcessMind.
Configuration
- Prérequis : vous devez disposer d’un compte utilisateur autorisé à accéder au module Business Intelligence de R1 RCM et à y créer des rapports personnalisés.
- Type de rapport : utilisez une requête personnalisée ou un générateur de rapports avancé permettant d’extraire des données complexes et d’utiliser des instructions UNION ALL pour combiner différents ensembles de données.
- Période : pour maîtriser les performances et le volume de données, limitez l’extraction à une période précise. Pour la première analyse, nous recommandons de commencer par une période de 3 à 6 mois. Appliquez le filtre de date au champ d’horodatage principal de chaque activité.
- Filtres clés : en plus de la période, vous pouvez filtrer par
Facility ID,Payer TypeouBilling Departmentafin de cibler certains domaines opérationnels et de réduire le volume exporté. - Format d’exportation : sélectionnez toujours CSV comme format de sortie. Vous obtiendrez ainsi un fichier structuré que les outils de Process Mining pourront facilement traiter.
- Planification : si le module de rapports R1 RCM le permet, planifiez l’exécution récurrente du rapport, par exemple chaque semaine ou chaque mois, afin d’actualiser automatiquement les données pour un suivi continu.
Exemple de requête 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; Prêt à commencer ?
Utilisez ce modèle pour simplifier la collecte de vos données et commencer à optimiser la gestion de votre cycle de revenus. Nous sommes là pour vous accompagner à chaque étape.
Optimisez dès maintenant votre processus R1 RCM : améliorez l’efficacité du cycle de revenus
Éliminez les goulots d’étranglement du cycle de revenus, réduisez le temps de cycle de 30 % et améliorez votre trésorerie.
Aucune carte bancaire requise. Commencez en quelques minutes.