Votre Modèle de Données de Gestion du cycle de revenus (RCM)

Epic Resolute
Votre Modèle de Données de Gestion du cycle de revenus (RCM)

Votre Modèle de Données de Gestion du cycle de revenus (RCM)

Ce modèle fournit un guide détaillé pour la collecte des `données` nécessaires à l'optimisation de votre processus de gestion du cycle de revenus. Il décrit les `attributs` de données essentiels, les activités clés à suivre et des conseils pratiques pour extraire ces informations de vos systèmes sources. Utilisez cette ressource pour vous assurer de disposer de tous les points de données requis pour analyser et améliorer efficacement vos processus.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Guide d'extraction
Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Attributs de Gestion du cycle de revenus (RCM)

Ces champs de données sont recommandés pour être inclus dans votre `journal d'événements` afin d'obtenir une analyse et une optimisation approfondie du processus de gestion du cycle de revenus.
3 Obligatoire 6 Recommandé 10 Facultatif
Nom Descriptionn
Événement de facturation
BillingEvent
L'identifiant unique pour une seule prestation de service ou livraison de produit qui génère une charge, servant d'identifiant principal de dossier (case ID).
Descriptionn

L'événement de facturation est l'identifiant central qui relie toutes les activités au sein du cycle de revenus pour un élément facturable spécifique. Il commence lorsqu'un service est rendu et se termine lorsque le compte est entièrement réglé ou clôturé.

Dans l'analyse par Process Mining, cet attribut est indispensable pour reconstruire le parcours complet de chaque frais. Il permet le suivi d'activités telles que la saisie des frais, la soumission de réclamations, l'enregistrement des paiements et la gestion des refus pour les événements de facturation individuels, offrant une vue claire du flux de processus et de ses variations.

Pourquoi est-ce important ? :

C'est l'ID Case clé, essentiel pour lier toutes les étapes de processus connexes afin d'analyser le cycle de vie complet de la génération et du recouvrement des revenus pour chaque service.

Source des données :

Il s'agit souvent d'un identifiant unique pour un compte hospitalier (HAR) ou une session de facturation spécifique dans Epic Resolute. Consultez la documentation d'Epic Resolute pour des tables spécifiques comme HAR ou les enregistrements de session de facturation.

Exemples
BE10098765BE2001, 2, 3, 45BE30054321
Horodatage de l'événement
EventTimestamp
La date et l'heure précises auxquelles une activité ou un événement spécifique s'est produit.
Descriptionn

L'Event Horodatage enregistre le moment où une activité a eu lieu. Ces données temporelles sont critiques pour comprendre le moment et la séquence des événements dans le cycle de revenus.

En analyse, les horodatages sont utilisés pour calculer les durées entre les activités, telles que le décalage de la saisie des frais ou le temps d'enregistrement des paiements. Ils permettent la découverte des points de blocage, la mesure des temps de cycle et l'analyse de la performance des processus sur différentes périodes. Des horodatages précis sont essentiels pour presque tous les KPI et dashboards basés sur le temps.

Pourquoi est-ce important ? :

Cet attribut est indispensable pour le calcul de toutes les métriques temporelles, y compris les temps de cycle et les durées, qui sont clées pour identifier les retards et les inefficacités.

Source des données :

Trouvé dans les tables de journal de transactions ou d'événements au sein d'Epic Resolute, associé à chaque activité enregistrée. Les champs sont souvent nommés avec des suffixes comme Dt, DTTM, ou Time.

Exemples
2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z
Nom de l'activité
ActivityName
Le nom de l'`événement` ou de la tâche spécifique effectuée dans le processus de gestion du cycle de revenus.
Descriptionn

Cet attribut décrit une seule étape du cycle de revenus, telle que 'Frais Saisis', 'Réclamation Soumise au Payeur' ou 'paiement reçu'. Chaque activité représente un jalon distinct dans le processus de facturation et de recouvrement des paiements pour un service.

L'analyse des activités est le fondement du Process Mining. Elle facilite la visualisation de la cartographie des processus, l'identification des chemins communs, la découverte des points de blocage entre les étapes et la mesure de la conformité aux procédures opératoires standard.

Pourquoi est-ce important ? :

Définit les étapes de la cartographie des processus, rendant possible la visualisation, l'analyse et l'optimisation du flux de travail dans le cycle de revenus.

Source des données :

Ceci est généralement dérivé des journaux d'événements, des pistes d'audit ou des enregistrements de changement de statut dans les modules de facturation et de réclamations d'Epic Resolute.

Exemples
Charges capturéesDemande de remboursement soumise au payeurpaiement reçuCompte clos
Code de motif de refus
DenialReasonCode
Un code standardisé indiquant la raison pour laquelle un payeur a refusé une demande de remboursement soumise.
Descriptionn

Lorsqu'un payeur rejette une réclamation, il fournit un code de motif qui explique le refus, tel que 'Service non couvert', 'Réclamation en double' ou 'Nécessite des informations supplémentaires'. Ces codes sont souvent normalisés comme Claim Adjustment Reason Codes (CARC).

Cet attribut est l'élément central du tableau de bord 'Taux et raisons de refus de réclamation'. L'analyse de la fréquence des différents codes de refus aide à identifier les causes profondes des refus, tels que des problèmes d'accréditation, des erreurs de codage ou des pré-autorisations manquantes, permettant des initiatives d'amélioration ciblées.

Pourquoi est-ce important ? :

Explique directement pourquoi les demandes de remboursement sont rejetées, fournissant les perspectives concrètes nécessaires pour réduire les taux de refus, prévenir les pertes de revenus et accélérer les paiements.

Source des données :

Ces données se trouvent dans les transactions de réponse aux réclamations (comme un fichier ANSI 835) reçues des payeurs et stockées dans le module de gestion des réclamations d'Epic Resolute.

Exemples
CO-16 : La demande de remboursement/le service manque d'informationsOA-18 : Demande de remboursement/service en doublePR-96 : Frais non couverts
Motif de l'ajustement
AdjustmentReason
La raison d'un ajustement manuel ou automatisé apporté au solde du compte d'un patient.
Descriptionn

Cet attribut explique pourquoi un solde de compte a été modifié en dehors d'un paiement ou d'une charge standard. Les raisons peuvent inclure des allocations contractuelles avec les payeurs, des radiations de petits soldes ou des corrections pour les erreurs d'enregistrement.

Ceci est indispensable pour le tableau de bord 'Volume d'ajustement de compte par type'. En analysant les motifs d'ajustement, les organisations peuvent identifier les sources de pertes de revenus, comprendre l'impact des contrats des payeurs et repérer les inefficacités ou erreurs potentielles dans le processus de facturation.

Pourquoi est-ce important ? :

Fournit un aperçu des pertes de revenus et de la précision de la facturation en expliquant pourquoi les soldes des comptes sont modifiés, aidant ainsi à réduire les radiations inutiles.

Source des données :

Situé dans les détails de transaction pour les entrées d'ajustement au sein du module de comptabilité patient d'Epic Resolute.

Exemples
Marge contractuelleRadiation de petit soldeCorrection de frais en double
Service de facturation
BillingDepartment
Le service ou l'équipe fonctionnelle responsable de l'`événement` de facturation ou de l'activité.
Descriptionn

Cet attribut indique l'unité organisationnelle, telle que 'Facturation hospitalisation', 'Facturation ambulatoire' ou 'Équipe de gestion des refus', qui est associée à l'événement de facturation ou a effectué une activité spécifique.

Cette dimension est indispensablele pour le tableau de bord 'Indicateurs de performance du service de facturation', permettant des comparaisons côte à côte des indicateurs clés tels que les taux de refus ou les temps de saisie des frais. Elle aide la direction à identifier les services très performants, à standardiser les meilleures pratiques et à allouer les ressources efficacement.

Pourquoi est-ce important ? :

Permet l'analyse comparative des performances entre différents départements, aidant à identifier les meilleures pratiques et les domaines nécessitant une amélioration ou des ressources supplémentaires.

Source des données :

Ces informationsns peuvent être liées à l'enregistrement de l'utilisateur, au compte patient ou à l'emplacement du service au sein d'Epic Resolute.

Exemples
Facturation de cardiologieRadiologie RCMBureau central de facturation
Solde impayé
OutstandingBalance
Le montant restant dû par le payeur ou le patient pour l'`événement` de facturation.
Descriptionn

Cet attribut représente le solde actuel des comptes clients pour un événement de facturation spécifique au moment de l'activité. Il reflète le statut financier du case tout au long de son cycle de vie.

Le solde impayé est impératif pour les rapports financiers et pour le 'Rapport de vieillissement des soldes impayés'. L'analyse de cette valeur au fil du temps et selon différentes dimensions comme le payeur ou le service aide à prioriser les efforts de recouvrement, à gérer les flux de trésorerie et à évaluer les risques financiers.

Pourquoi est-ce important ? :

Mesure directement l'impact financier des retards de processus et est indispensable pour prioriser les recouvrements, gérer la trésorerie et comprendre les créances clients.

Source des données :

Il s'agit d'un champ central sur l'enregistrement du compte patient ou du compte hospitalier (HAR) dans Epic Resolute. C'est un solde courant qui est mis à jour par les transactions financières.

Exemples
1500.00250.750.00
Type de service
ServiceType
La catégorie ou le type de service médical qui a été rendu.
Descriptionn

Cet attribut classifie le service facturable, par exemple, comme 'Radiologie', 'Chirurgie', 'Consultation' ou 'Visite aux urgences'. Il fournit un contexte clinique aux données financières.

L'analyse du cycle de revenus par type de service peut découvrir des variations de processus spécifiques à certaines zones cliniques. Par exemple, les procédures chirurgicales peuvent avoir des exigences de saisie des frais et d'autorisation plus complexes qu'une consultation de bureau standard, entraînant différents comportements et défis de processus.

Pourquoi est-ce important ? :

Fournit un contexte clinique aux données financières, permettant d'analyser comment les différents types de services médicaux impactent le processus de gestion du cycle de revenus et son efficacité.

Source des données :

Dérivé du fichier maître de description des frais (CDM), de la ligne de service ou du département associé à la transaction de frais dans Epic.

Exemples
Chirurgie hospitalièreRadiologie ambulatoireServices d'urgence
Utilisateur responsable
ResponsibleUser
L'identifiant de l'utilisateur ou du collaborateur ayant effectué l'action.e l'employé qui a effectué l'activité.
Descriptionn

Cet attribut capture l'ID utilisateur, le nom ou le numéro d'employé de la personne responsable de l'accomplissement d'une tâche spécifique dans le cycle de revenus. Il peut s'agir du clinicien qui a saisi les frais, du facturier qui a soumis une réclamation ou du collecteur qui a assuré le suivi d'un refus.

L'analyse par utilisateur aide à identifier les meilleurs collaborateurs les plus performants, à cerner les besoins en formation et à comprendre la répartition de la charge de travail. Elle est indispensablele pour la gestion des performances et pour l'investigation des écarts de processus associées à des individus ou des rôles spécifiques.

Pourquoi est-ce important ? :

Permet l'analyse des performances par individu ou par rôle, aidant à identifier les opportunités de formation, les déséquilibres de charge de travail et les points de blocage liés aux ressources.

Source des données :

Généralement disponible dans les pistes d'audit ou les logs de transaction au sein d'Epic Resolute, souvent lié à une table de données maîtres des utilisateurs (par exemple, enregistrement EMP).

Exemples
j.doebsmith123User7890
Date d'échéance du paiement
PaymentDueDate
La date à laquelle le paiement pour le service facturé est attendu.
Descriptionn

Cet attribut spécifie la date limite de paiement, telle qu'indiquée sur la facture ou déterminée par les contrats des payeurs. Il sert de référence pour mesurer la ponctualité des paiements.

La date d'échéance du paiement est indispensablele pour la création du 'Rapport de vieillissement des soldes impayés'. En comparant la date actuelle à la date d'échéance des soldes ouverts, les comptes clients peuvent être classés en catégories de vieillissement (aging buckets) (par exemple, 0-30 jours, 31-60 jours de retard), ce qui aide à prioriser les efforts de recouvrement sur les comptes les plus en retard.

Pourquoi est-ce important ? :

Sert de base à l'analyse du vieillissement des comptes clients, ce qui est impératif pour prioriser les recouvrements et gérer les risques financiers liés aux factures impayées.

Source des données :

Cette date est souvent calculée en fonction de la date de la facture et des conditions de paiement stockées dans le contrat du payeur ou les informations du compte patient dans Epic.

Exemples
2023-05-302023-06-152023-07-01
Dernière mise à jour des données
LastDataUpdate
L'horodatage indiquant la dernière actualisation ou extraction des données de cet événement depuis le système source.
Descriptionn

Cet attribut montre la fraîcheur des données. Il indique la dernière fois que l'enregistrement a été extrait d'Epic Resolute dans l'ensemble de données de Process Mining.

Ceci est important pour comprendre la pertinence de l'analyse et à des fins de validation des données. Il aide les utilisateurs à savoir s'ils consultent les informations les plus récentes disponibles et est indispensable pour la gestion des cycles d'actualisation des données.

Pourquoi est-ce important ? :

Garantit aux utilisateurs comprennent la réactualisation des données qu'ils analysent, ce qui est indispensable pour prendre des décisions commerciales précises et à jour.

Source des données :

Ce horodatage est ajouté par le processus ETL (Extract, Transform, Load) lors de l'ingestion des données.

Exemples
2023-06-10T02:00:00Z2023-06-11T02:00:00Z
Est Automatisé
IsAutomated
Un indicateur booléen signalant si l'activité a été réalisée par un système ou un processus automatisé.
Descriptionn

Ce drapeau distingue les tâches exécutées automatiquement par le système, telles que la génération automatisée de réclamations ou les vérifications d'éligibilité, et celles effectuées manuellement par un utilisateur.

L'analyse de cet attribut aide à comprendre le niveau d'automatisation dans le processus. Il peut être utilisé pour comparer l'efficacité et les taux d'erreur des activités automatisées par rapport aux activités manuelles, identifier les opportunités d'automatisation supplémentaire et surveiller la performance des bots ou des règles système existantes.

Pourquoi est-ce important ? :

Distingue les activités pilotées par le système des activités pilotées par l'humain, ce qui est indispensable pour évaluer l'impact de l'automatisation et identifier de nouvelles opportunités d'automatisation.

Source des données :

Ceci est souvent dérivé en vérifiant si l'utilisateur responsable (ResponsibleUser) d'une activité est un compte système ou de service, ou en signalant des noms d'activités spécifiques connues pour être automatisées.

Exemples
truefaux
Heure de fin de l'événement
EventEndTime
Le `horodatage` indiquant quand une activité a été terminée, utile pour calculer la durée de l'activité.
Descriptionn

Cet attribut enregistre l'heure de fin d'une activité. Alors que de nombreuses activités sont des événements instantanés où StartTime est égal à EndTime, certaines tâches ont une durée mesurable, comme un appel de suivi de refus.

Lorsque disponible, EndTime permet le calcul direct du temps de traitement de l'activité ('EndTime' - 'StartTime'). Ceci est plus précis que d'inférer la durée à partir de l'heure de début de l'activité suivante, car cela tient compte du temps d'inactivité entre les étapes. C'est un composant clé pour le calcul de l'attribut 'ProcessingTime'.

Pourquoi est-ce important ? :

Permet le calcul précis de la durée de chaque activité, ce qui est impératif pour identifier les tâches chronophages et mesurer la productivité des ressources.

Source des données :

Ceci peut être disponible dans certains modules Epic Resolute qui suivent le début et la fin des tâches, tels que les workqueue ou les logs de gestion d'activité. Souvent, il n'est pas explicitement suivi.

Exemples
2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z
ID du patient
PatientId
L'identifiant unique du patient recevant le service.
Descriptionn

Cet attribut est le Numéro de Dossier Médical (NDM) ou tout autre identifiant unique pour le patient. Il relie l'événement de facturation financier à un individu spécifique.

Bien que non généralement utilisé comme dimension d'analyse principale pour protéger la vie privée des patients, il est indispensable pour la validation des données et peut être utilisé pour agréger tous les événements de facturation pour un seul patient afin de comprendre leur parcours financier global. Il est également essentiel pour toute intégration potentielle avec les données des processus cliniques.

Pourquoi est-ce important ? :

Lie les données financières à un patient spécifique, permettant la validation des données et le potentiel d'une analyse plus large du parcours complet d'un patient, bien qu'il doive être traité avec prudence en raison des préoccupations de confidentialité.

Source des données :

Un identifiant clé trouvé dans Epic, lié aux dossiers d'enregistrement et de compte du patient.

Exemples
MRN-1, 2, 3, 4567MRN-8765432MRN-5551, 2, 3, 4
Montant Ajusté
AdjustedAmount
La valeur monétaire d'une transaction d'ajustement.
Descriptionn

Ce champ enregistre le montant spécifique en dollars d'un ajustement de compte. Il peut être une valeur positive ou négative, représentant un crédit ou un débit au solde du compte.

Ce montant est la principale métrique pour le tableau de bord 'Volume d'ajustement de compte par type'. L'addition de cette valeur par motif d'ajustement fournit une image claire de l'impact financier des différents types d'ajustements, tels que le montant des revenus radiés en raison d'obligations contractuelles par rapport à ce qui est perdu en raison d'erreurs corrigeables.

Pourquoi est-ce important ? :

Quantifie l'impact financier des ajustements de compte, rendant possible la mesure des pertes de revenus et du coût des inexactitudes de facturation.

Source des données :

Situé dans les tables de détails des transactions financières d'Epic Resolute, associé aux transactions de type ajustement.

Exemples
-1250.45-50.0025.10
Nom du payeur
PayerName
Le nom de la compagnie d'assurance, de l'entité gouvernementale ou de toute autre partie responsable du paiement.
Descriptionn

Cet attribut identifie le payeur principal associé à l'événement de facturation, tel que 'Blue Cross Blue Shield', 'Medicare' ou 'Aetna'. En cas d'auto-paiement, il peut indiquer le patient.

Segmenter le processus par payeur est une technique d'analyse puissante. 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 plus complexes. Cet aperçu permet d'adapter les stratégies de facturation à des payeurs spécifiques pour améliorer l'efficacité et la rapidité des paiements.

Pourquoi est-ce important ? :

Permet l'analyse des performances par payeur, révélant quels payeurs ont des taux de refus élevés ou des cycles de paiement lents, permettant ainsi des stratégies de suivi ciblées.

Source des données :

Ces informationsns font partie des détails de la couverture du patient, liées au compte hospitalier (HAR) dans Epic Resolute.

Exemples
Medicare partie BUnitedHealthcareAetna PPO
Numéro de Sinistre
ClaimId
L'identifiant unique attribué à une réclamation d'assurance soumise à un payeur.
Descriptionn

Cet attribut est l'ID spécifique du formulaire de réclamation (par exemple, un CMS-1500 ou UB-04) envoyé à un payeur. Un seul événement de facturation peut impliquer plusieurs réclamations si les services sont refacturés ou contestés.

Le suivi par ID de réclamation est utile pour une analyse détaillée des sous-processus de soumission de réclamation et de gestion des refus. Il aide à distinguer les activités liées à la réclamation initiale de celles liées à une réclamation ultérieure, resoumise, pour le même service.

Pourquoi est-ce important ? :

Fournit un identifiant granulaire pour le suivi du cycle de vie de chaque soumission de réclamation spécifique, ce qui est impératif pour l'analyse des nouvelles soumissions et des appels.

Source des données :

Généré par le module de gestion des demandes de remboursement d'Epic Resolute lorsqu'une demande de remboursement est créée. Il est stocké dans les tables de données des demandes de remboursement.

Exemples
CLM-2023-98765CLAIM-001, 2, 3, 45623189A4567
Système source
SourceSystem
Le système d'information d'où proviennent les `données`.
Descriptionn

Cet attribut identifie le système source de l'enregistrement, qui dans ce contexte est Epic Resolute. Dans des environnements avec plusieurs systèmes intégrés, ce champ aide à différencier les origines des données.

Bien qu'il puisse sembler redondant dans une vue mono-système, c'est une bonne pratique pour la gouvernance des données et l'évolutivité. Il garantit la clarté si des données provenant d'autres systèmes, comme une plateforme d'agence de recouvrement séparée, sont intégrées ultérieurement.

Pourquoi est-ce important ? :

Fournit une traçabilité et un contexte cruciaux pour les données, assurant la clarté sur l'origine des données, ce qui est indispensable à la gouvernance des données et le dépannage.

Source des données :

Il s'agit généralement d'une valeur statique ajoutée pendant le processus d'extraction et de transformation des données pour étiqueter l'origine du jeu de données.

Exemples
Epic ResoluteEpicResolute_V2023
Temps total du cycle de revenus
TotalRevenueCycleTime
La durée totale calculée entre le premier `événement` de service et le paiement final ou la clôture du compte.
Descriptionn

Il s'agit d'un KPI au niveau du case qui mesure la durée complet du cycle de revenus pour un seul événement de facturation. Il est généralement calculé comme la différence de temps entre l'activité 'Service Rendu' et l'activité finale 'paiement reçu' ou 'Compte Clôturé'.

Cette métrique de haut niveau offre une vue d'ensemble complète de l'efficacité globale du processus RCM. Le suivi de ce KPI au fil du temps aide à mesurer l'impact des initiatives d'amélioration des processus et fournit un indicateur clé de la vitesse de conversion des liquidités.

Pourquoi est-ce important ? :

Fournit une vue d'ensemble, complet, de l'efficacité des processus, mesurant directement le temps nécessaire pour convertir un service en trésorerie.

Source des données :

Il s'agit d'une métrique calculée dans l'outil de Process Mining en filtrant les premier et dernier événements de chaque case et en trouvant la différence de temps.

Exemples
259200038880005184000
Obligatoire Recommandé Facultatif

Activités de Gestion du cycle de revenus (RCM)

Voici les étapes clés du processus et les jalons à capturer dans votre *log* d'événements pour une découverte de processus et une mesure de performance précises.
7 Recommandé 5 Facultatif
Activité Descriptionn
Charges capturées
Représente l'enregistrement formel des frais facturables pour les services rendus. Dans Epic, il s'agit généralement d'une transaction explicite enregistrée sur le compte du patient, souvent générée automatiquement à partir d'actions cliniques ou saisie manuellement.
Pourquoi est-ce important ? :

Il s'agit d'un premier jalon critique. Mesurer la vitesse et la précision de la saisie des frais aide à accélérer le processus de facturation et à assurer que tous les services fournis sont facturés.

Source des données :

Explicitement enregistré dans les journaux de transactions de Resolute. Chaque frais est une entrée distincte avec une date d'imputation, une date de service et un montant, souvent trouvée dans des tables comme ARPB_TRANSACTIONS.

Capture

Capturer les transactions d'imputation des frais à partir du journal des transactions financières du système.

Type d'événement explicit
Compte clos
Il s'agit de l'activité finale, signifiant que le solde impayé de l'`événement` de facturation a atteint zéro et qu'il n'y a plus d'activités en attente. Cela peut être dû à un paiement intégral, des ajustements ou une radiation.
Pourquoi est-ce important ? :

Cet événement marque l'achèvement réussi du cycle de revenus pour un événement de facturation. La durée complet du service à la clôture est un KPI critique pour l'efficacité globale des processus.

Source des données :

Il s'agit généralement d'un événement inféré. Il est déterminé en identifiant le moment où le solde du compte pour l'événement de facturation devient nul et le reste.

Capture

Déduit en calculant un total cumulé du solde du compte et en identifiant l'horodatage de la dernière transaction qui a ramené le solde à zéro.

Type d'événement inferred
Demande de remboursement refusée par le payeur
Représente la réception d'une notification du payeur indiquant que la réclamation a été refusée. Cela est capturé lorsque Epic traite un avis de virement électronique (fichier 835) ou lorsqu'un utilisateur enregistre manuellement un refus.
Pourquoi est-ce important ? :

Cette activité déclenche une boucle de reprises critique. L'analyse des raisons et des volumes de refus est indispensablele pour identifier les causes profondes, améliorer les taux de paiement dès la première soumission et réduire les retards de recouvrement.

Source des données :

Explicitement enregistré comme une transaction ou une mise à jour de statut sur la demande de remboursement. Les informations de refus, y compris les codes de motif, sont généralement reçues électroniquement et imputées au compte.

Capture

Filtrer par types de transaction spécifiques ou mises à jour du statut des demandes de remboursement qui indiquent un refus.

Type d'événement explicit
Demande de remboursement soumise au payeur
Ceci marque l'`événement` où la réclamation est officiellement envoyée au payeur d'assurance pour adjudication. Dans Epic, il s'agit d'un `événement` suivi, enregistré lorsque le fichier de réclamation électronique est transmis à la chambre de compensation ou au payeur.
Pourquoi est-ce important ? :

Ce jalon est impératif car il lance le décompte du délai de paiement du payeur. L'analyse de ceci aide à mesurer l'efficacité du processus de transmission des réclamations et soutient le KPI de temps de livraison de la facture au payeur.

Source des données :

Il s'agit d'un événement explicite enregistré dans Resolute. L'enregistrement de la réclamation aura un statut de soumission et un horodatage indiquant quand elle a été envoyée.

Capture

Capturer l'horodatage associé au changement de statut de la demande de remboursement à 'Soumise' ou 'Transmise'.

Type d'événement explicit
Paiement imputé au compte
C'est l'`événement` où un paiement reçu est appliqué ou alloué à des frais spécifiques sur le compte du patient. Cette action réduit le solde impayé de l'`événement` de facturation.
Pourquoi est-ce important ? :

Une imputation efficace des paiements est indispensablele pour maintenir des soldes de compte précis et clôturer les événements de facturation. Elle permet l'identification correcte des soldes restants pour la facturation secondaire ou le recouvrement.

Source des données :

Il s'agit d'une transaction explicite dans Resolute. L'enregistrement du paiement lie une transaction de paiement à une ou plusieurs transactions de frais, ce qui est enregistré dans les tables de détails de transaction.

Capture

Capturer l'enregistrement de transaction qui applique un paiement à une charge, identifiable par des types de transaction spécifiques.

Type d'événement explicit
paiement reçu
Représente la réception du paiement d'un payeur ou d'un patient. Cet `événement` est généralement enregistré lorsqu'un avis de virement électronique (ERA) est chargé ou qu'un chèque manuel est saisi dans le système.
Pourquoi est-ce important ? :

Cette activité est un jalon majeur indiquant l'arrivée de revenus. Le temps entre la soumission de la réclamation et la réception du paiement est une mesure clé de la performance des comptes clients.

Source des données :

Explicitement enregistré comme une transaction de paiement dans Resolute. Ces transactions sont journalisées avec une date, une source et un montant, souvent avant d'être entièrement imputées aux frais individuels.

Capture

Capturer les transactions de paiement à partir du journal des transactions financières, souvent identifiées par des types de transaction spécifiques.

Type d'événement explicit
Service Rendu
Cette activité marque le moment où un service clinique est fourni au patient, ce qui initie l'`événement` de facturation. Ceci est souvent capturé à partir du DME Epic (EpicCare) lorsqu'un clinicien valide une visite ou une procédure.
Pourquoi est-ce important ? :

Il s'agit de l'événement de début principal pour le cycle de revenus. L'analyse du temps entre ce point et la saisie des frais est indispensable pour identifier les retards dans l'initiation de la facturation et les pertes de revenus potentielles.

Source des données :

Cet événement est généralement inféré à partir des horodatages de service ou de visite dans les modules cliniques qui sont liés au compte de facturation. La date de service sur la transaction de frais est le point de données clé.

Capture

Déduit de la date de service associée à la première transaction de frais pour l'événement de facturation.

Type d'événement inferred
Ajustement de compte effectué
Cette activité représente une transaction de non-paiement qui modifie le solde du compte, comme un ajustement contractuel, une radiation de petit solde ou une remise commerciale. Elle est enregistrée comme un type de transaction spécifique.
Pourquoi est-ce important ? :

L'analyse des ajustements est indispensablele pour identifier les fuites de revenus. Des volumes élevés de certains types d'ajustements peuvent indiquer des problèmes avec les barèmes de frais, les contrats ou les politiques internes.

Source des données :

Explicitement enregistré comme transactions d'ajustement dans les journaux financiers de Resolute. Chaque ajustement aura un type ou un code de motif spécifique associé.

Capture

Filtrer par types de transaction qui correspondent à des ajustements financiers ou à des radiations.

Type d'événement explicit
Réclamation générée
Cette activité signifie la création par le système d'une réclamation ou d'une facture formelle basée sur les frais saisis. C'est une étape préparatoire avant l'envoi de la réclamation au payeur ou au patient.
Pourquoi est-ce important ? :

Le suivi de la génération des réclamations aide à isoler les retards entre la saisie des frais et leur préparation pour la soumission. C'est une étape interne clé qui peut impacter la ponctualité globale de la facturation.

Source des données :

Ceci est généralement enregistré lorsqu'un job de lot de facturation ou de génération de réclamations est exécuté. Le système enregistrera un horodatage lorsque le fichier de réclamation (comme un fichier 837) est créé pour un compte donné.

Capture

Identifier les entrées de journal ou les changements de statut indiquant que la demande de remboursement a été compilée et est prête à être soumise.

Type d'événement explicit
Réclamation resoumise
Cet `événement` se produit après qu'une réclamation refusée a été corrigée et est renvoyée au payeur. Il s'agit d'un `événement` de soumission distinct qui est lié à la réclamation originale.
Pourquoi est-ce important ? :

Il s'agit d'une partie clé de la boucle de reprises. Mesurer le temps de nouvelle soumission et le taux de réussite des réclamations resoumises est indispensable à comprendre l'efficacité du processus de résolution des refus.

Source des données :

Il s'agit d'un événement explicite similaire à la soumission initiale, mais souvent signalé comme une nouvelle soumission. L'enregistrement de la réclamation affichera un nouveau horodatage de soumission et pourra inclure un code de nouvelle soumission.

Capture

Capturer l'horodatage pour une soumission de demande de remboursement signalée comme une correction ou une nouvelle soumission.

Type d'événement explicit
Solde envoyé au recouvrement
Ceci marque le moment où un solde de compte impayé est transféré à un processus de recouvrement interne ou externe. Il s'agit souvent d'un changement de statut explicite sur le compte ou l'`événement` de facturation.
Pourquoi est-ce important ? :

Cette activité déclenche la phase finale de recouvrement des soldes impayés. Le suivi du taux de réussite et du temps de cycle du processus de recouvrement est indispensable à minimiser les créances irrécouvrables.

Source des données :

Il s'agit généralement d'un événement explicite. Epic dispose de fonctions pour transférer des comptes à des agences de recouvrement, ce qui crée une entrée de log ou un changement de statut sur le compte.

Capture

Identifier le changement de statut ou la transaction qui indique qu'un compte a été confié à une agence de recouvrement.

Type d'événement explicit
Suivi du refus initié
Cette activité marque le début du processus interne d'examen et de résolution d'une réclamation refusée. Elle est souvent capturée lorsqu'un utilisateur prend en charge la réclamation refusée dans une `workqueue` ou en modifie le statut.
Pourquoi est-ce important ? :

Le suivi de ceci aide à mesurer la réactivité de l'équipe de gestion des refus. Les retards entre un refus et le début du suivi peuvent prolonger inutilement le cycle de revenus.

Source des données :

Ceci est généralement inféré à partir des changements de statut ou de l'historique d'affectation de la réclamation dans les workqueue d'Epic. Par exemple, le statut de la réclamation pourrait passer de 'Refusé' à 'En Examen'.

Capture

Déduire d'un changement de statut de la demande de remboursement ou d'une entrée de journal d'audit montrant qu'un utilisateur a commencé à traiter le refus.

Type d'événement inferred
Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données d'Epic Resolute