Votre modèle de données pour la gestion du cycle de revenus

R1 RCM
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

Ce modèle de données vous indique clairement quelles informations recueillir pour analyser votre processus de gestion du cycle de revenus. Il présente les attributs essentiels à collecter et les activités importantes à suivre. Vous y trouverez également des conseils pour extraire ces données de votre système R1 RCM et préparer efficacement votre projet de Process Mining.
  • Attributs recommandés à collecter
  • Activités clés à suivre pour découvrir le processus
  • Guide détaillé d’extraction pour R1 RCM
Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Attributs de la gestion du cycle de revenus

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail votre processus de gestion du cycle de revenus.
5 Obligatoire 6 Recommandé 8 Facultatif
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
Obligatoire Recommandé Facultatif

Activités de gestion du cycle de revenus

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir avec précision le processus de gestion du cycle de revenus.
6 Recommandé 8 Facultatif
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
Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de R1 RCM

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.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Commencez en quelques minutes.