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 la découverte de processus
- Guide d'extraction détaillé pour R1 RCM
Attributs de gestion du cycle de revenus
| Nom | Description | ||
|---|---|---|---|
| Événement de Facturation BillingEvent | L'identifiant unique pour un seul service ou article facturable, servant d'identifiant de cas principal pour le suivi de l'ensemble du cycle de revenus. | ||
| Description L'ID d'événement de facturation représente une instance distincte d'une prestation de service ou de produit entraînant une charge. Il agit comme le fil conducteur central reliant toutes les activités connexes, depuis la prestation de service initiale et la capture des charges jusqu'à la soumission de la réclamation, l'enregistrement du paiement et la clôture éventuelle du compte. En Process Mining, l'analyse du cycle de vie de chaque événement de facturation permet une vue complète du cycle de revenus de bout en bout. Il est utilisé pour tracer le parcours complet d'une seule charge, identifier les chemins courants, mesurer les temps de cycle entre les étapes clés et comprendre les variations qui entraînent des retards ou des fuites de revenus. Pourquoi c'est important Cet identifiant est essentiel pour regrouper toutes les activités connexes en un seul cas, permettant une analyse complète et précise du cycle de revenus pour chaque événement facturable. Où obtenir Ceci est la clé primaire reliant diverses tables liées aux rencontres patient, aux charges, aux réclamations et aux paiements. Consultez la documentation R1 RCM pour le champ spécifique, souvent lié à un identifiant de rencontre ou de réclamation. Exemples BE-2023-0012345BE-2023-0054321BE-2024-0098765 | |||
| Heure de l'événement EventTime | L'horodatage indiquant quand une activité ou un événement spécifique s'est produit. | ||
| Description L'heure de l'événement fournit la date et l'heure précises auxquelles une activité a été enregistrée dans le système. Cette information temporelle est fondamentale pour comprendre le processus à partir d'une analyse temporelle. Dans le process mining, cet horodatage est utilisé pour ordonner les événements chronologiquement et calculer les durées entre les activités, ce qui est essentiel pour l'analyse des performances. Il permet le calcul de métriques clés telles que le temps de cycle, le temps de traitement et le temps d'attente, qui sont essentiels pour identifier les goulots d'étranglement et mesurer l'efficacité. Pourquoi c'est important Cet horodatage est la base de toutes les analyses liées au temps, y compris le calcul des temps de cycle, l'identification des goulots d'étranglement et la surveillance des performances des processus par rapport aux SLA. Où obtenir Généralement trouvé comme un champ 'Date de création', 'Horodatage' ou 'Date de dernière mise à jour' associé à chaque enregistrement de transaction ou de changement de statut dans R1 RCM. Exemples 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| Nom de l'activité ActivityName | Le nom de l'événement commercial ou de la tâche spécifique qui s'est produit à un moment donné au sein du processus du cycle de revenus. | ||
| Description Cet attribut décrit une étape ou un jalon unique au sein du processus de gestion du cycle de revenus pour un événement de facturation donné. Les activités représentent le travail effectué, telles que 'Charges capturées', 'Réclamation soumise' ou 'Paiement enregistré'. L'analyse de la séquence des activités est au cœur du Process Mining. Elle permet de découvrir le flux de processus réel, d'identifier les goulots d'étranglement où les activités prennent trop de temps à démarrer, et de détecter les boucles de retravail où les activités sont répétées inutilement, comme 'Réclamation refusée' suivie de 'Retravail du refus initié'. Pourquoi c'est important Il définit les étapes du processus, permettant la visualisation de la carte du processus, le calcul des temps de transition et l'identification des déviations de processus et des retravaux. Où obtenir Ces informations sont généralement dérivées des journaux d'événements, des enregistrements de changement de statut ou des codes de transaction au sein de divers modules R1 RCM. Elles peuvent nécessiter un mappage des codes techniques vers des noms compréhensibles pour le métier. Exemples Frais CapturésSinistre DéclaréAdjudication du Payeur ReçuePaiement comptabiliséCompte Clôturé | |||
| Dernière mise à jour des données LastDataUpdate | Le timestamp de la dernière actualisation des données ou de l'extraction du système source. | ||
| Description Cet attribut indique la dernière fois que les données pour l'analyse Process Mining ont été mises à jour. Il fournit un contexte sur l'actualisation des données analysées. Ces informations sont importantes pour le reporting et la création de tableaux de bord, car elles indiquent à l'utilisateur la pertinence des informations sur les processus. Elles aident à gérer les attentes concernant l'actualité des données et garantissent que les décisions sont prises sur la base d'un cadre temporel compris. Pourquoi c'est important Fournit un contexte crucial sur l'actualisation des données, garantissant que les analystes et les parties prenantes sont informés de la pertinence des informations sur les processus. Où obtenir Cet horodatage est généré pendant le processus d'extraction, de transformation et de chargement (ETL) des données et est généralement appliqué à l'ensemble du jeu de données. Exemples 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Système source SourceSystem | Le système d'origine à 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 pour un événement particulier. Dans un environnement complexe comme celui de la santé, les données peuvent provenir d'un EMR, d'un module de facturation, d'une chambre de compensation de réclamations ou d'une plateforme de recouvrement. Comprendre le système source est crucial pour la validation des données et pour l'analyse des variations de processus qui peuvent être spécifiques à certains systèmes. Cela aide à dépanner les incohérences de données et à comprendre le paysage technologique du processus. Pourquoi c'est important Identifie l'origine des données, ce qui est crucial pour la gouvernance des données, la validation et la compréhension de la manière dont les différents systèmes interagissent au sein du processus de bout en bout. Où obtenir Il s'agit souvent d'une valeur statique ajoutée lors du processus d'extraction de données, identifiant le système (par exemple, 'R1 RCM') d'où proviennent les données. Exemples R1 RCMCernerEpic | |||
| Code Motif de Refus DenialReasonCode | Un code standardisé du payeur expliquant pourquoi une réclamation a été refusée. | ||
| Description Lorsqu'un payeur refuse une réclamation, il fournit un code de raison, tel qu'un CARC (Claim Adjustment Reason Code), pour expliquer la décision. Ces codes sont standardisés et indiquent des problèmes tels que 'Service non couvert' ou 'Réclamation en double'. Cet attribut est extrêmement important pour la gestion des refus. En analysant la fréquence des différents codes de raison de refus, les organisations peuvent identifier et traiter les causes profondes des refus, qu'elles soient liées à l'éligibilité du patient, à des erreurs de codage ou à un manque de nécessité médicale. Cela soutient directement les efforts visant à réduire le retravail et à accélérer le flux de trésorerie. Pourquoi c'est important Fournit la raison spécifique des refus de réclamation, permettant une analyse des causes profondes pour réduire les refus futurs, diminuer le retravail et améliorer les taux de paiement au premier passage. Où obtenir Ces informations sont reçues dans l'avis de virement électronique (ERA ou fichier 835) du payeur et sont stockées dans le module de gestion des réclamations de R1 RCM. Exemples CO-16 : La réclamation/le service manque d'informations nécessaires à l'adjudication.PR-97 : Le bénéfice de ce service est inclus dans le paiement/l'allocation d'un autre service.CO-22 : Ces soins peuvent être couverts par un autre payeur selon la coordination des avantages.OA-18 : Réclamation/service en double exact. | |||
| Montant de la facture InvoiceAmount | La valeur monétaire totale des charges sur la facture ou la réclamation. | ||
| Description Cet attribut représente le montant total facturé pour les services rendus lors d'un événement de facturation donné. Il reflète les revenus attendus de la réclamation. L'analyse du montant de la facture est cruciale pour le Process Mining financier. Elle permet de prioriser les réclamations à forte valeur, de comprendre l'impact financier des retards ou des refus de processus, et de segmenter le processus en fonction de la valeur. Par exemple, une analyse pourrait révéler que les réclamations dépassant un certain montant suivent un parcours de processus différent et plus manuel. Pourquoi c'est important Fournit un contexte financier au processus, permettant d'analyser comment les variations de processus impactent les revenus, et aide à prioriser les cas à forte valeur ajoutée pour l'amélioration. Où obtenir Situé dans la table d'en-tête de réclamation ou de facture principale dans R1 RCM, souvent nommé 'TotalBilledAmount' ou similaire. Exemples 150.002500.7585.5012000.00 | |||
| Nom du payeur PayerName | Le nom de la compagnie d'assurance, de l'entité gouvernementale ou du patient responsable du paiement. | ||
| Description Cet attribut identifie le payeur principal de la réclamation. Il peut s'agir d'un assureur commercial comme Aetna, d'un payeur gouvernemental comme Medicare, ou du patient lui-même pour les portions auto-payées. L'analyse du processus par payeur est fondamentale pour la gestion du cycle de revenus. Elle peut révéler que certains payeurs ont des taux de refus plus élevés, des cycles de paiement plus longs ou des exigences de soumission plus complexes. Ces informations permettent à l'organisation d'adapter ses processus et ses ressources pour gérer efficacement les comportements spécifiques aux payeurs. Pourquoi c'est important Permet la segmentation du processus par payeur pour identifier les retards spécifiques aux payeurs, les modèles de refus ou les comportements de paiement, ce qui est crucial pour optimiser les revenus. Où obtenir Trouvé dans les informations d'assurance ou démographiques du patient liées à la réclamation dans R1 RCM. Exemples MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaAuto-paiement | |||
| Service de facturation BillingDepartment | Le département ou l'équipe fonctionnelle responsable de l'exécution de l'activité. | ||
| Description Cet attribut spécifie l'unité organisationnelle, telle que 'Saisie des charges', 'Soumission des réclamations' ou 'Gestion des refus', qui a exécuté une étape particulière du processus. Il aide à comprendre comment le travail est transféré entre les différentes équipes. Ceci est crucial pour analyser le débit départemental et identifier les goulots d'étranglement inter-fonctionnels. En filtrant la carte de processus par département, les organisations peuvent voir où les transferts sont fluides et où des retards se produisent, soutenant l'allocation des ressources et l'optimisation des processus organisationnels. Pourquoi c'est important Permet l'analyse de la performance des processus par unité organisationnelle, aidant à identifier les goulots d'étranglement spécifiques aux équipes, les contraintes de ressources ou les meilleures pratiques. Où obtenir Ceci peut être dérivé du profil de l'utilisateur dans R1 RCM ou stocké comme un 'Code de département' dans les données de transaction. Exemples Capture des FraisGestion des sinistresRefus et AppelsEnregistrement du paiement | |||
| Statut de la facture InvoiceStatus | Le statut actuel de la facture ou de la réclamation dans son cycle de vie. | ||
| Description Cet attribut indique le dernier état connu d'un événement de facturation, tel que 'Soumise', 'Payée', 'Refusée' ou 'En recouvrement'. Il fournit un aperçu de l'état d'une facture dans le processus à un moment donné. Le statut de la facture est vital pour créer des rapports de vieillissement et surveiller la santé des comptes débiteurs. En Process Mining, il peut être utilisé pour filtrer les cas bloqués dans un état particulier ou pour analyser les résultats de différentes variantes de processus, par exemple, en comparant les parcours des réclamations 'Payées' et 'Refusées'. Pourquoi c'est important Fournit une vue de l'état actuel de chaque cas, essentielle pour l'élaboration de rapports de vieillissement et l'analyse des résultats finaux des différents parcours de processus. Où obtenir Il s'agit généralement d'un champ de statut sur l'enregistrement principal de la réclamation ou du compte dans R1 RCM. Exemples Soumission en attenteSoumis au payeurRefuséEntièrement payéeEn Recouvrement | |||
| Utilisateur assigné AssignedUser | L'ID utilisateur ou le nom de l'employé qui a effectué l'activité. | ||
| Description Cet attribut identifie l'individu responsable de l'exécution d'une tâche spécifique dans le processus. Il peut s'agir du facturier qui a créé la réclamation, de l'analyste qui a retravaillé un refus, ou du spécialiste qui a enregistré un paiement. L'analyse par utilisateur aide à comprendre la répartition de la charge de travail, la performance individuelle et les besoins en formation. Elle peut mettre en évidence quels utilisateurs sont les plus efficaces ou lesquels peuvent être associés à des taux d'erreur plus élevés, permettant une gestion ciblée et des efforts d'amélioration des processus. Pourquoi c'est important Permet l'analyse de la performance des équipes et des individus, la distribution de la charge de travail, et aide à identifier les opportunités de formation ou les déviations de processus spécifiques aux utilisateurs. Où obtenir Généralement trouvé comme un champ 'ID utilisateur', 'Processeur' ou 'Mis à jour par' dans les journaux de transactions au sein de R1 RCM. Exemples jdoeasmithp.jonesBOT_RPA01 | |||
| Code de service ServiceCode | Le code de facturation pour le service ou la procédure spécifique fourni(e), tel qu'un code CPT ou HCPCS. | ||
| Description Les codes de service, comme les codes CPT (Current Procedural Terminology), sont des codes médicaux standardisés utilisés pour déclarer les procédures et services médicaux, chirurgicaux et diagnostiques aux payeurs pour remboursement. L'analyse du processus par code de service est essentielle pour identifier les problèmes de facturation liés à des types de soins spécifiques. Elle peut mettre en évidence quelles procédures sont le plus souvent refusées, ont les cycles de paiement les plus longs ou nécessitent le plus de retravail, permettant des améliorations ciblées des pratiques de codage et de facturation. Pourquoi c'est important Permet l'analyse des processus basée sur le type de service rendu, ce qui est essentiel pour identifier les modèles de refus ou les retards de paiement associés à des procédures spécifiques. Où obtenir Ces informations se trouvent au niveau de la ligne d'article pour chaque charge ou réclamation au sein de R1 RCM. Exemples 992139928573560 | |||
| Est Automatisé IsAutomated | Un indicateur signalant si l'activité a été réalisée par un système automatisé ou un utilisateur humain. | ||
| Description Cet attribut booléen distingue les tâches exécutées par une automatisation logicielle, comme un bot RPA pour la soumission de réclamations, et les tâches effectuées manuellement par un employé. L'analyse de cet attribut est essentielle pour comprendre l'impact et l'efficacité des initiatives d'automatisation. Elle permet de comparer la vitesse, le coût et les taux d'erreur des processus automatisés par rapport aux processus manuels, aidant à identifier de nouvelles opportunités d'automatisation et à mesurer le ROI des bots existants. Pourquoi c'est important Distingue les activités humaines des activités pilotées par le système, ce qui est crucial pour mesurer l'impact de l'automation sur l'efficacité, le coût et la qualité des processus. Où obtenir Ceci peut être dérivé du champ 'AssignedUser', où des ID d'utilisateur spécifiques sont réservés aux bots (par exemple, 'BOT_RPA01'). Alternativement, certains systèmes disposent d'un champ dédié pour signaler les transactions automatisées. Exemples truefaux | |||
| Est un retravail IsRework | Un indicateur calculé qui identifie les activités faisant partie d'une boucle de retravail, telles que la soumission d'une réclamation refusée. | ||
| Description Cet attribut est un indicateur booléen généralement calculé lors de l'analyse Process Mining. Il devient 'vrai' si une activité est une répétition d'une étape précédente ou fait partie d'une séquence indiquant une correction d'erreur, par exemple, toute activité suivant 'Réclamation refusée'. L'identification du retravail est l'une des capacités les plus puissantes du Process Mining. Elle quantifie la quantité d'efforts, de temps et de ressources gaspillés dans un processus. En signalant le retravail, les organisations peuvent concentrer leurs efforts d'amélioration sur la prévention des erreurs qui le causent en premier lieu, entraînant des gains d'efficacité significatifs. Pourquoi c'est important Aide à quantifier la fréquence et l'impact du retravail, tel que les refus de réclamation, permettant une analyse ciblée pour réduire les inefficacités et les efforts inutiles. Où obtenir Ce n'est pas un champ dans le système source. Il est calculé par l'outil de Process Mining basé sur la séquence des activités, tel que la détection lorsqu'une 'Réclamation soumise' activité se produit plus d'une fois pour le même cas. Exemples truefaux | |||
| ID patient PatientId | L'identifiant unique du patient ayant reçu le service. | ||
| Description Cet attribut est l'ID unique attribué à un patient au sein du système de santé, souvent appelé Numéro de Dossier Médical (NDM). Bien que les soins individuels aux patients ne soient pas l'objectif principal, l'ID Patient peut être utilisé pour analyser les problèmes de facturation récurrents pour le même patient au fil du temps. Il peut également aider à segmenter le processus par données démographiques ou historiques du patient s'il est lié à d'autres données patient, révélant potentiellement des problèmes systémiques affectant certains groupes de patients. Pourquoi c'est important Permet l'analyse des événements de facturation au niveau du patient, aidant à identifier les problèmes récurrents ou les schémas pour des patients spécifiques sur plusieurs rencontres. Où obtenir Cet identifiant est un élément central des données démographiques du patient liées à chaque rencontre et réclamation dans R1 RCM. Exemples MRN837262MRN937281MRN103847 | |||
| Montant de l'ajustement AdjustmentAmount | La valeur monétaire d'un ajustement effectué au solde du compte. | ||
| Description Cet attribut capture la valeur de tout ajustement financier effectué sur le compte d'un patient après la facturation initiale. Les ajustements peuvent être positifs ou négatifs et incluent les allocations contractuelles, les radiations ou les corrections. Le suivi des montants d'ajustement est essentiel pour comprendre l'intégrité des revenus. Des niveaux élevés d'ajustements négatifs peuvent indiquer des fuites de revenus dues à des problèmes tels qu'une capture de charges incorrecte ou des dettes irrécouvrables. L'analyse de ces données aide à identifier l'impact financier des erreurs de facturation et des inefficacités de recouvrement. Pourquoi c'est important Quantifie les fuites de revenus et les corrections financières, aidant à déterminer l'impact monétaire des inexactitudes de facturation, des obligations contractuelles ou des mauvaises créances. Où obtenir Trouvé dans les journaux de transactions liés aux ajustements de compte ou à l'enregistrement des paiements dans R1 RCM. Exemples -50.2520.00-1200.00 | |||
| Motif de l'ajustement AdjustmentReason | La raison fournie pour un ajustement financier, tel qu'une 'Allocation contractuelle' ou une 'Radiation pour créance irrécouvrable'. | ||
| Description Cet attribut fournit le contexte expliquant pourquoi un ajustement financier a été effectué sur un compte. Les raisons sont souvent des codes ou des descriptions standardisés qui catégorisent le type d'ajustement. L'analyse des raisons d'ajustement aide à diagnostiquer les causes profondes des fuites de revenus. Par exemple, une fréquence élevée de 'Radiation de petit solde' pourrait suggérer un processus de recouvrement inefficace pour les petits montants, tandis que des 'Allocations contractuelles' fréquentes sont une partie attendue des négociations avec les payeurs. Cette analyse soutient le tableau de bord d'audit des ajustements de facturation et de la conformité. Pourquoi c'est important Explique le 'pourquoi' des ajustements de revenus, aidant à identifier les causes profondes des pertes de revenus, telles que les problèmes contractuels, les erreurs de facturation ou les échecs de recouvrement. Où obtenir Il s'agit généralement d'un champ de code ou de texte dans le même enregistrement de transaction que le montant d'ajustement (AdjustmentAmount) dans R1 RCM. Exemples Allocation ContractuellePassation en perte de créances irrécouvrablesRadiation de Petit SoldeCorrection d'Erreur de Facturation | |||
| Résultat du Recouvrement CollectionOutcome | Le résultat final des activités de recouvrement pour un solde impayé. | ||
| Description Cet attribut décrit le résultat des efforts de recouvrement pour un compte en souffrance. Les résultats possibles incluent 'Payé en totalité', 'Réglé', 'Classé en créance irrécouvrable' ou 'Non résolu'. Le suivi des résultats de recouvrement est essentiel pour évaluer l'efficacité du processus de recouvrement. En analysant quelles activités mènent à quels résultats, les organisations peuvent optimiser leurs stratégies de recouvrement, améliorer les taux de recouvrement et prendre des décisions éclairées sur le moment d'arrêter les efforts de recouvrement et de radier les soldes. Cela soutient le tableau de bord de performance des activités de recouvrement. Pourquoi c'est important Mesure l'efficacité du processus de recouvrement en suivant la résolution finale des comptes en souffrance, aidant à optimiser les stratégies de recouvrement. Où obtenir Il s'agit probablement d'un champ de statut sur le compte patient ou dans un module de recouvrement dédié au sein de R1 RCM. Exemples Entièrement payéeRéglé pour un montant inférieurEnvoyé à une agence externeRadié en créances irrécouvrables | |||
| Temps de cycle Service-au-Paiement ServiceToPaymentCycleTime | La durée totale calculée entre le moment où un service a été rendu et celui où le paiement final a été enregistré. | ||
| Description Cette métrique mesure la durée de bout en bout du cycle de revenus pour un seul événement de facturation. Elle représente le temps total qu'il faut à une organisation pour convertir un service fourni en liquidités. C'est un indicateur clé de performance (KPI) critique pour la santé financière. L'analyse de cette durée aide à identifier les principaux domaines d'accélération des processus. En décomposant le temps de cycle en ses parties composantes, telles que le 'temps de facturation' et le 'temps de paiement', les organisations peuvent identifier les plus grandes opportunités d'amélioration du flux de trésorerie. Pourquoi c'est important Il s'agit d'un KPI critique de haut niveau qui mesure l'efficacité globale du cycle de conversion de trésorerie, impactant directement le flux de trésorerie de l'organisation. Où obtenir Ceci est une métrique calculée. C'est la différence de temps entre l'horodatage de l'activité 'Service rendu' et l'activité 'Paiement enregistré' pour un événement de facturation donné. Exemples 35 jours 8 heures92 jours 4 heures15 jours 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 avec un solde nul et le compte est officiellement clôturé. Cela signifie la réussite du cycle de revenus pour cette rencontre spécifique. | ||
| Pourquoi c'est important Ceci est l'événement final principal du 'parcours idéal' pour le processus. La mesure du temps de cycle de clôture de compte aide à garantir que les tâches administratives sont complétées efficacement et que les enregistrements sont finalisés. Où obtenir Cet événement est inféré lorsque le solde du compte atteint zéro et qu'un statut final de 'Fermé' ou 'Payé en totalité' est appliqué. L'horodatage est pris de la dernière transaction financière qui a mis le solde à zéro. Capture Déduit lorsque le solde du compte devient zéro et qu'un statut 'Closed' est appliqué, avec un horodatage d'activité final. Type d'événement inferred | |||
| Frais Capturés | Cette activité signifie l'enregistrement formel de tous les services, procédures et fournitures facturables pour une rencontre patient. C'est une étape critique de saisie de données qui traduit les activités cliniques en transactions financières. | ||
| Pourquoi c'est important Marque le transfert 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 réclamations et aide à identifier les arriérés de saisie des frais. Où obtenir Capturé au sein du module de saisie des frais de R1 RCM ou reçu via une interface d'un DSE (Dossier de Santé Électronique). L'événement est généralement marqué par un journal de transaction spécifique ou l'horodatage de création de l'enregistrement des frais. Capture Identifié par l'horodatage de création de l'enregistrement de transaction de frais dans la table de facturation. Type d'événement explicit | |||
| Paiement comptabilisé | Le paiement reçu est officiellement appliqué au compte du patient, réduisant le solde impayé. C'est l'étape finale du rapprochement d'un paiement avec les services facturés. | ||
| Pourquoi c'est important Cette activité constitue le point final pour le calcul des temps de cycle Service-au-Paiement et Enregistrement des paiements. Elle confirme que les revenus sont reconnus et que les comptes sont mis à jour avec précision. Où obtenir Ceci est enregistré comme une transaction financière explicite dans le module de comptabilité patient de R1 RCM. Chaque enregistrement comprend une date, un montant et une source. Capture Enregistré comme une transaction spécifique avec une date d'enregistrement lorsqu'un utilisateur ou un processus automatisé applique 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, mais les fonds n'ont pas encore été appliqués au compte ou aux lignes de service spécifiques. | ||
| Pourquoi c'est important Représente un flux de trésorerie entrant. L'écart de temps entre 'Paiement reçu' et 'Paiement enregistré' est un indicateur clé pour comprendre l'efficacité du back-office et les retards de rapprochement de trésorerie. Où obtenir Capturé à partir de fichiers de remise électronique des payeurs ou du traitement des paiements des patients. L'événement correspond à la date de dépôt ou à la date de réception du fichier. Capture Enregistré à partir de la date d'effet du paiement du fichier ERA ou de la date de transaction d'un paiement patient. Type d'événement explicit | |||
| Service Rendu | Représente le moment où un service ou une procédure facturable est complété pour un patient. Cet événement est souvent capturé à partir d'un système clinique ou de planification et sert de déclencheur pour le cycle de revenus. | ||
| Pourquoi c'est important C'est le point de départ du KPI du temps de cycle Service-au-Paiement. L'analyse du temps à partir de cet événement aide à identifier les retards en amont dans le cycle de revenus. Où obtenir Généralement issu d'un Dossier de Santé Électronique (DSE) ou d'un système de gestion de cabinet intégré à R1 RCM. Il est souvent inféré d'une date de service ou d'un horodatage 'Procédure terminée' dans le dossier du patient. Capture Déduit de l'horodatage de la 'Date de Service' associé à la rencontre patient. Type d'événement inferred | |||
| Sinistre Déclaré | La réclamation générée est soumise électroniquement au payeur responsable, tel qu'une compagnie d'assurance. Cela marque la première communication externe du processus de facturation pour obtenir le remboursement. | ||
| Pourquoi c'est important Une étape cruciale qui déclenche le délai de remboursement du payeur. Le suivi de cela aide à surveiller les retards de soumission et garantit la conformité des dépôts en temps voulu avec les payeurs. Où obtenir Cet événement est enregistré comme une transaction explicite lorsque la réclamation est transmise à une chambre de compensation. Le système enregistre l'horodatage de la soumission et les détails de confirmation. Capture Enregistré explicitement comme une transaction avec un horodatage de soumission lorsque la réclamation est envoyée via la chambre de compensation. Type d'événement explicit | |||
| Activité de Recouvrement Initiée | Le compte du patient est devenu en souffrance, et des efforts de recouvrement proactifs sont initiés. Cela peut aller des lettres de rappel automatisées au placement auprès d'un spécialiste du recouvrement. | ||
| Pourquoi c'est important Marque le début du 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ù obtenir Cet événement est probablement enregistré ou inféré d'un changement de statut lorsqu'un compte est déplacé dans une file d'attente de recouvrement ou se voit attribuer un code de statut de recouvrement au sein de R1 RCM. Capture Déduit d'un changement de statut du compte vers un statut 'Collections' ou 'Delinquent'. Type d'événement inferred | |||
| Adjudication du Payeur Reçue | Le système reçoit une réponse du payeur concernant la réclamation soumise, souvent sous la forme d'un fichier Electronic Remittance Advice (ERA). Cette réponse détaille ce qui a été payé, refusé ou ajusté. | ||
| Pourquoi c'est important Cet événement est un embranchement crucial dans le processus, déterminant si l'étape suivante est l'enregistrement des paiements ou la gestion des refus. L'analyse de ceci aide à comprendre le comportement des payeurs et la vitesse des paiements. Où obtenir Capturé lorsqu'un fichier de remise électronique, tel qu'un fichier ANSI 835, du payeur est traité par R1 RCM. L'événement est marqué par l'horodatage de traitement de ce fichier. Capture Enregistré lors de l'ingestion et du traitement du fichier Electronic Remittance Advice (ERA/835). Type d'événement explicit | |||
| Ajustement de Compte Effectué | Une transaction de non-paiement est enregistrée sur le compte pour modifier le solde. Cela peut inclure des ajustements contractuels basés sur les accords avec les payeurs, des annulations de petits soldes ou des corrections. | ||
| Pourquoi c'est important Des volumes élevés d'ajustements peuvent indiquer des problèmes avec les barèmes de frais, la gestion des contrats ou des erreurs de facturation. Le suivi des ajustements est essentiel pour analyser l'intégrité des revenus. Où obtenir Enregistré comme un type de transaction spécifique dans le module de comptabilité patient de R1 RCM. Chaque ajustement possède un code, un montant et une date d'enregistrement. Capture Enregistré comme une transaction d'ajustement distincte, identifiable par un code de transaction unique. Type d'événement explicit | |||
| Compte Passé en Créance Douteuse | Tous les efforts de recouvrement ont été épuisés, et le solde restant du compte est considéré comme irrécouvrable. Le solde est passé en pertes sur créances irrécouvrables, représentant une perte de revenus finale. | ||
| Pourquoi c'est important Cela représente un résultat de processus négatif et une perte de revenus directe. L'analyse des cas qui aboutissent à des créances irrécouvrables peut révéler des schémas de non-paiement et des opportunités d'améliorer le recouvrement. Où obtenir Il s'agit généralement d'une transaction explicite dans R1 RCM où le solde impayé est déplacé vers une catégorie spécifique de créances irrécouvrables, souvent déclenchée par un utilisateur ou des règles de vieillissement automatisées. Capture Enregistré comme une transaction financière spécifique pour annuler le solde, souvent associée à un transfert vers une agence de recouvrement externe. Type d'événement explicit | |||
| Relevé Patient Généré | Après l'adjudication par l'assurance, un relevé est créé pour le patient détaillant le solde restant dont il est responsable. Cela peut concerner les quotes-parts, les franchises ou les services non couverts. | ||
| Pourquoi c'est important Cette activité initie la partie paiement patient du cycle de revenus. L'analyse de son calendrier et de sa fréquence est importante pour la gestion du recouvrement auprès des patients et du flux de trésorerie. Où obtenir Généralement capturé comme un événement enregistré lorsqu'un processus par lots est exécuté pour créer et imprimer ou envoyer électroniquement des relevés de patients. R1 RCM enregistrerait la date à laquelle le relevé a été généré. Capture Enregistré comme une transaction lorsque le processus par lots pour générer les relevés de patients est exécuté. Type d'événement explicit | |||
| Retravail du Refus Initié | Un utilisateur ou un flux de travail automatisé commence à enquêter et à résoudre une réclamation refusée. Cela peut impliquer la correction du codage, la soumission de documents ou l'appel de la décision du payeur. | ||
| Pourquoi c'est important Suit le début de la boucle de retravail coûteuse pour les réclamations refusées. Mesurer le temps passé dans cette phase est essentiel pour comprendre l'efficacité de l'équipe de gestion des refus. Où obtenir Cet événement est souvent inféré d'un changement de statut de la réclamation refusée à 'Retravail en cours' ou 'En cours d'examen' au sein d'une file d'attente de travail ou d'un module de gestion des refus de R1 RCM. Capture Déduit d'un changement de statut dans une file d'attente de travail de gestion des refus ou par la première action utilisateur sur une réclamation refusée. Type d'événement inferred | |||
| Sinistre créé | Une réclamation de facturation formelle est générée dans le système sur la base des frais capturés. Cela implique la compilation des données démographiques du patient, des informations d'assurance et des codes de service dans un format standardisé. | ||
| Pourquoi c'est important C'est un jalon interne clé avant la soumission externe. Les retards ici peuvent indiquer 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ù obtenir Ceci est un événement système interne au sein de R1 RCM. Il est probablement capturé comme un changement de statut sur le compte de facturation ou par l'horodatage de création de l'entité de réclamation elle-même. Capture Déduit du changement de statut en 'Claim Generated' ou de l'horodatage de création de l'enregistrement de réclamation. Type d'événement inferred | |||
| Sinistre Refusé | Le payeur a refusé de payer la réclamation, en totalité ou pour des postes spécifiques. La raison du refus est enregistrée, initiant un processus de retravail et d'appel. | ||
| Pourquoi c'est important Cette activité met en évidence les fuites de revenus et l'inefficacité des processus. L'analyse des raisons de refus est essentielle pour identifier les causes profondes et améliorer les taux d'acceptation des réclamations au premier passage. Où obtenir Ce n'est pas un événement discret, mais plutôt un statut inféré des détails d'un fichier ERA traité. Des codes de refus spécifiques au sein des données de remise déclenchent un changement de statut sur la réclamation. Capture Déduit des codes de refus présents dans le fichier ERA traité, qui modifient le statut de la réclamation en 'Denied'. Type d'événement inferred | |||
Guides d'extraction
Étapes
- Connectez-vous à la plateforme R1 RCM avec un compte utilisateur disposant des autorisations nécessaires pour accéder aux modules de Business Intelligence ou de reporting.
- Naviguez vers la section de reporting de la plateforme. Celle-ci peut être intitulée "Business Intelligence", "Reporting Portal" ou "Analytics".
- Localisez l'outil de création d'un nouveau rapport ou d'une nouvelle requête personnalisée. Cela vous permet de définir les champs de données et la logique spécifiques pour l'extraction.
- Étant donné que R1 RCM ne fournit pas de journal d'événements unifié et pré-construit, vous devez en construire un en combinant des données provenant de différentes sources. La configuration de requête fournie utilise une approche UNION ALL pour fusionner les événements de divers objets métier en un seul journal chronologique.
- Copiez la requête complète fournie dans la section "Requête" de ce document et collez-la dans l'éditeur de requête ou l'interface de configuration du rapport personnalisé.
- Configurez les paramètres du rapport, en particulier la plage de dates. Définissez les espaces réservés
'{StartDate}'et'{EndDate}'dans la requête pour définir la période d'extraction, telle que les 6 derniers mois. - Ajoutez tout autre filtre nécessaire à la configuration du rapport, tel que le filtrage par installations, départements ou groupes de payeurs spécifiques pour affiner la portée des données.
- Exécutez le rapport. Cela exécutera la requête sur la base de données R1 RCM et générera les résultats en fonction de vos paramètres spécifiés.
- Une fois le rapport terminé, trouvez l'option d'exporter les données. Sélectionnez CSV (Comma Separated Values) comme format d'exportation, car il est directement compatible avec ProcessMind.
- Téléchargez le fichier CSV généré et ouvrez-le pour effectuer une révision rapide. Assurez-vous que les en-têtes de colonne correspondent aux attributs requis :
BillingEvent,ActivityName,EventTime,SourceSystemetLastDataUpdate. - Vérifiez que les formats de date et d'heure dans les colonnes
EventTimeetLastDataUpdatesont cohérents avant de télécharger le fichier dans ProcessMind.
Configuration
- Prérequis : Un compte utilisateur avec les permissions suffisantes pour accéder et créer des rapports personnalisés au sein du module de Business Intelligence de R1 RCM est requis.
- Type de rapport : Utilisez une requête personnalisée ou un générateur de rapports avancé qui permet une récupération complexe des données et l'utilisation d'instructions UNION ALL pour combiner différents ensembles de données.
- Plage de dates : Pour gérer la performance et le volume des données, il est crucial de filtrer par une période spécifique. Nous recommandons de commencer avec une fenêtre de 3 à 6 mois pour l'analyse initiale. Appliquez le filtre de date au champ d'horodatage principal pour chaque activité.
- Filtres clés : Au-delà de la plage de dates, envisagez d'appliquer des filtres pour
Facility ID,Payer TypeouBilling Departmentafin de concentrer l'analyse sur des zones opérationnelles spécifiques et de réduire la taille de l'exportation. - Format d'exportation : Sélectionnez toujours le format CSV pour l'exportation. Cela garantit un fichier propre et structuré qui peut être facilement analysé par les outils de process mining.
- Planification : Si le module de reporting R1 RCM le prend en charge, envisagez de planifier l'exécution de ce rapport sur une base récurrente (par exemple, hebdomadaire ou mensuelle) pour automatiser les actualisations de données pour un suivi continu.
a Exemple de requête config
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;