Votre template de données de Revenue Cycle Management
Votre template de données de Revenue Cycle Management
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction
Attributs de Gestion du Cycle de Revenus
| Nom | Description | ||
|---|---|---|---|
| É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'ID de cas principal. | ||
| Description L'événement de facturation sert d'identifiant principal de cas, reliant toutes les activités liées à un service fourni ou un produit livré qui génère une charge. Cela permet un suivi complet du cycle de vie de la génération et de la collecte des revenus pour chaque article ou service facturable distinct. En Process Mining, l'analyse du processus par événement de facturation permet aux organisations de visualiser le parcours complet de bout en bout, de la prestation de services au paiement final ou à la clôture du compte. Cette vue est cruciale pour identifier les goulots d'étranglement, mesurer les temps de cycle et comprendre les variations dans la manière dont les différentes factures sont traitées. Pourquoi c'est important C'est l'ID de cas essentiel qui relie toutes les activités du cycle de revenus connexes, permettant une vue de processus complète de bout en bout pour l'analyse. Où obtenir C'est la clé primaire reliant les enregistrements dans les tables de facturation et de demandes de remboursement principales d'Optum360. Consultez la documentation Optum360 pour les noms spécifiques de tables et de champs. Exemples BE-2023-0012345BE-2023-0012346BE-2023-0012347 | |||
| 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 est l'horodatage associé à chaque activité, marquant la date et l'heure précises de son occurrence. Ces données temporelles sont essentielles pour construire la séquence chronologique des événements pour chaque cas. En analyse, l'Heure de l'Événement est utilisée pour calculer les temps de cycle entre les activités, mesurer la durée des cas et identifier les goulets d'étranglement où un temps significatif est passé à attendre. C'est la pierre angulaire de toute analyse de processus et mesure de performance basée sur le temps. Pourquoi c'est important Cet Où obtenir Cette information est généralement stockée à côté de chaque transaction ou enregistrement de changement de statut dans les tables de base de données d'Optum360. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z | |||
| Nom de l'activité ActivityName | Le nom d'un événement ou d'une tâche spécifique survenu au sein du processus de gestion du cycle de revenus. | ||
| Description Le Nom de l'Activité décrit une étape du processus du cycle de revenus, telle que "Réclamation Soumise au Payeur" ou "Paiement Reçu". Cet attribut est fondamental pour le Process Mining, car il définit les nœuds de la carte de processus. En analysant la séquence et la fréquence des activités, les organisations peuvent visualiser le flux de processus réel, identifier les déviations par rapport à la procédure standard et localiser les boucles de reprise courantes. Cette analyse est essentielle pour comprendre les inefficacités de processus et les problèmes de conformité. Pourquoi c'est important Cet attribut définit les étapes individuelles du processus, constituant la base de la carte de processus et permettant toutes les analyses basées sur le flux. Où obtenir Ceci est généralement dérivé des event logs, des enregistrements de changement de statut ou des codes de transaction spécifiques au sein des tables opérationnelles d'Optum360. Exemples Sinistre crééRéclamation soumise au payeurPaiement ReçuRefus reçuCompte clos | |||
| Code de motif de refus DenialReasonCode | Un code standardisé du payeur expliquant pourquoi une réclamation a été refusée. | ||
| Description Lorsqu'un payeur refuse une demande de remboursement, il fournit un Denial Reason Code qui explique le problème, tel que "Service non couvert" ou "Demande en double". Ces codes sont cruciaux pour comprendre les causes profondes des retards de revenus et du retraitement. L'analyse de ces codes permet à l'équipe de gestion des refus de prioriser son travail, d'identifier les tendances et de mettre en œuvre des actions correctives. Par exemple, une fréquence élevée de refus pour "Informations manquantes" peut indiquer un problème dans le processus de création des demandes de remboursement. Cette analyse est centrale pour réduire le taux de refus et accélérer les flux de trésorerie. Pourquoi c'est important Fournit la cause profonde des refus de réclamations, permettant des interventions ciblées pour prévenir les refus futurs et réduire les coûteuses reprises. Où obtenir Ce code est inclus dans les fichiers d'avis de virement électronique (ERA) reçus des payeurs et est stocké dans le module de gestion des demandes de remboursement d'Optum360. Exemples CO-16: La réclamation/le service manque d'informationsPR-97: Le bénéfice de ce service est inclus dans le paiement/l'indemnité pour un autre service/procédureOA-18: Réclamation/service en double | |||
| ID patient PatientId | L'identifiant unique du patient qui a reçu les services. | ||
| Description Le Patient ID est un identifiant unique attribué à chaque patient au sein du système de santé. Il relie plusieurs événements de facturation à un seul patient, permettant une analyse centrée sur le patient. En utilisant le Patient ID, les analystes peuvent étudier les modèles liés à des patients spécifiques, tels que les réadmissions fréquentes ou un historique de refus de demandes de remboursement. Il permet également la segmentation du processus en fonction des données démographiques ou de l'historique du patient, ce qui peut révéler des informations importantes pour améliorer l'expérience financière du patient. Pourquoi c'est important Permet une analyse centrée sur le patient, aidant à comprendre le parcours financier de bout en bout et à identifier les schémas pour des populations de patients spécifiques. Où obtenir Cet identifiant est un champ central dans les données de base patient et les tables de transactions au sein d'Optum360. Consultez la documentation Optum360 pour plus de détails. Exemples PAT-98765PAT-98766PAT-98767 | |||
| ID Payeur PayerId | L'identifiant unique de la compagnie d'assurance ou du payeur responsable de la demande de remboursement. | ||
| Description Le Payer ID identifie la compagnie d'assurance spécifique, le programme gouvernemental comme Medicare ou Medicaid, ou toute autre entité responsable du paiement de la demande de remboursement. Chaque payeur a souvent son propre ensemble de règles, d'exigences de soumission et de comportements de paiement. L'analyse du processus par Payer ID est critique pour le RCM. Elle permet d'identifier quels payeurs ont les cycles de paiement les plus longs, les taux de refus les plus élevés ou les processus d'appel les plus complexes. Cette information permet aux services de facturation d'adapter leurs stratégies pour différents payeurs afin d'améliorer la vitesse de recouvrement et de réduire la charge administrative. Pourquoi c'est important Segmenter le processus par payeur est essentiel pour identifier quels payeurs causent des retards ou des refus, permettant des améliorations ciblées dans la gestion des payeurs. Où obtenir Cette information est stockée sur chaque enregistrement de demande de remboursement au sein d'Optum360. Consultez la documentation Optum360 pour les noms de tables et de champs liés aux payeurs. Exemples PAYER-AETNAPAYER-BCBS-MAPAYER-MEDICAREPAYER-UHC | |||
| Montant Ajusté AdjustedAmount | La valeur monétaire des radiations, des ajustements contractuels ou des corrections apportées au montant facturé. | ||
| Description Le montant ajusté représente la part du montant facturé qui ne devrait pas être recouvrée en raison d'accords contractuels avec les payeurs, de corrections de facturation ou d'autres radiations. Il s'agit d'une réduction directe des revenus. Cet attribut est essentiel pour le 'Revenue Adjustment Impact' dashboard et l'indicateur clé de performance (KPI) 'Revenue Adjustment Rate'. L'analyse des ajustements permet d'identifier l'impact financier des contrats avec les payeurs et de trouver des opportunités pour minimiser les pertes de revenus grâce à une meilleure précision de la facturation ou à la négociation des contrats. Pourquoi c'est important Mesure directement la fuite de revenus et est essentiel pour calculer les KPI de performance financière et comprendre la rentabilité. Où obtenir Cette information se trouve dans les enregistrements de transaction d'ajustement au sein du système financier d'Optum360. Exemples 30,00250.2510.00 | |||
| Montant facturé BilledAmount | La valeur monétaire totale de toutes les charges soumises sur la demande de remboursement ou la facture. | ||
| Description Le Montant Facturé représente le coût brut des services rendus, avant tout paiement, ajustement ou radiation. C'est la valeur initiale du compte débiteur pour l'événement de facturation. Cet attribut est fondamental pour l'analyse financière au sein du Process Mining. Il est utilisé pour calculer des KPI clés comme le Taux d'Ajustement des Revenus, et il permet de segmenter les cas par valeur pour voir si les réclamations de grande valeur sont traitées différemment ou subissent plus de retards que les réclamations de faible valeur. Pourquoi c'est important Fournit le contexte financier pour chaque cas, permettant une analyse basée sur la valeur et le calcul de KPI financiers critiques. Où obtenir Ceci est un champ standard sur chaque demande de remboursement ou compte patient au sein des tables financières d'Optum360. Exemples 150.001250.7585.50 | |||
| Service de facturation BillingDepartment | Le département ou l'équipe interne qui a géré ou effectué l'activité de facturation. | ||
| Description L'attribut Département de Facturation identifie l'équipe spécifique ou la zone fonctionnelle au sein des opérations du cycle de revenus responsable d'une activité. Par exemple, différentes équipes peuvent gérer le codage, la soumission des factures et la gestion des refus. Cet attribut est essentiel pour l'évaluation comparative des performances, comme demandé par le 'Billing Department Performance Benchmarks' dashboard. Il permet aux dirigeants de comparer l'efficacité, la rapidité et la précision des différentes équipes, d'identifier les meilleures pratiques et d'allouer efficacement les ressources pour combler les lacunes de performance. Pourquoi c'est important Permet la comparaison des performances entre différentes équipes de facturation, aidant à identifier les groupes performants et les domaines nécessitant des améliorations. Où obtenir Ceci peut être dérivé de l'utilisateur effectuant la tâche ou d'un champ sur le compte qui indique la propriété. Consultez la documentation Optum360. Exemples Bureau central de facturationÉquipe de gestion des refusDépartement de codageServices financiers patients | |||
| Code de service ServiceCode | Le code de procédure (par exemple, CPT, HCPCS) qui identifie le service spécifique rendu. | ||
| Description Le Service Code est un code médical standardisé qui identifie précisément la procédure ou le service fourni au patient. Ces codes sont requis pour la facturation et sont un déterminant principal du remboursement. L'analyse du processus par Service Code peut révéler que certaines procédures sont plus sujettes aux refus, nécessitent plus de documentation ou ont des cycles de paiement plus longs. Cela permet une compréhension plus granulaire des défis du processus et peut éclairer les politiques de codage et de facturation pour des types de services spécifiques. Pourquoi c'est important Permet une analyse basée sur le type de service médical, ce qui peut révéler des schémas de refus ou de retards de paiement spécifiques à certaines procédures. Où obtenir Ce code est un élément fondamental des enregistrements de saisie des charges et de détails de demande de remboursement dans Optum360. Exemples 992137104527447 | |||
| 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 enregistre la date et l'heure de la dernière extraction des données du système source et de leur chargement dans l'outil de Process Mining. Il fournit un contexte sur la fraîcheur des données analysées. Ceci est important pour les analystes et les utilisateurs métier afin de comprendre s'ils visualisent les informations les plus récentes. Cela aide à gérer les attentes concernant la latence des données et est un élément clé de métadonnées pour tout projet d'analyse. Pourquoi c'est important Fournit un contexte crucial sur la fraîcheur des données, garantissant que les utilisateurs comprennent l'actualité de l'analyse. Où obtenir Cet horodatage est généralement généré et stocké par le processus d'extraction, de transformation et de chargement des données (ETL). Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Durée du cas CaseDuration | Le temps de cycle total pour un événement de facturation, de la première à la dernière activité. | ||
| Description La Durée du Cas mesure le temps total écoulé du tout premier événement au tout dernier événement pour un seul Événement de Facturation. C'est un KPI clé de haut niveau pour évaluer l'efficacité globale du processus. Cette métrique supporte directement le tableau de bord 'Vue d'ensemble du temps de cycle de bout en bout de la GCR' et le KPI 'Temps de cycle moyen de la GCR'. Suivre cela au fil du temps permet à la direction de voir l'impact des initiatives d'amélioration sur l'ensemble du cycle de revenus. Pourquoi c'est important Représente le temps de cycle de bout en bout du processus, un KPI critique pour mesurer la vitesse et l'efficacité globales du processus. Où obtenir Ceci est calculé en soustrayant l'horodatage du premier événement de l'horodatage du dernier événement pour chaque ID de cas 'BillingEvent' unique. Exemples 30 jours95 jours45 jours | |||
| Est un retravail IsRework | Un indicateur signalant si une activité fait partie d'une boucle de reprise, comme la gestion des refus ou les recours. | ||
| Description Est-ce que la Reprise est un indicateur booléen qui identifie les activités considérées comme une reprise sans valeur ajoutée, telles que "Reprise de Refus Démarrée" ou "Recours Soumis". Ces activités se produisent généralement lorsque le processus dévie de son "chemin idéal". Cet attribut aide à quantifier le volume de reprise dans le processus, qui est un indicateur direct d'inefficacité et de coût. Il est utilisé pour calculer le KPI "Taux de Reprise des Erreurs de Facturation" et supporte le tableau de bord "Identification des Goulets d'Étranglement et Boucles de Reprise" en facilitant le filtrage et la visualisation de ces boucles inefficaces. Pourquoi c'est important Aide à quantifier l'inefficacité des processus en signalant les activités qui représentent une reprise, facilitant ainsi la mesure et le ciblage des gaspillages. Où obtenir Ceci est généralement dérivé en utilisant la logique métier au sein de l'outil de Process Mining. Par exemple, toute activité suivant un événement "Refus reçu" pourrait être signalée comme retraitement. Exemples truefaux | |||
| Fournisseur de services ServiceProvider | Le clinicien, le département ou l'établissement qui a rendu le service facturable. | ||
| Description Cet attribut identifie le fournisseur spécifique, tel qu'un médecin, un thérapeute ou un service hospitalier, responsable de la prestation du service. Différents fournisseurs peuvent avoir des modèles de facturation ou des habitudes de documentation différents qui affectent le cycle de revenus. L'analyse par Service Provider peut aider à identifier les problèmes liés au charge capture, à la précision du codage ou à la qualité de la documentation qui proviennent du point de service. Elle peut mettre en évidence des opportunités de formation des fournisseurs ou d'amélioration des processus pour s'assurer que des demandes de remboursement sont générées sans erreur dès le départ. Pourquoi c'est important Aide à retracer les problèmes de facturation jusqu'à la source, permettant un retour d'information et une formation ciblés pour le personnel clinique afin d'améliorer la capture des charges et la documentation. Où obtenir Cette information est un élément clé de l'enregistrement de charge ou de demande de remboursement dans Optum360, souvent lié aux données de base du fournisseur. Exemples Dr Emily CarterDépartement de radiologieChirurgie généralePhysiothérapie | |||
| Heure de fin EndTime | L'horodatage indiquant quand une activité a été achevée. | ||
| Description L'End Time marque l'achèvement d'une activité. Alors que le Start Time indique quand un événement s'est produit, l'End Time est nécessaire pour calculer la durée des activités ayant un temps de traitement distinct, comme le 'Denial Rework Started' et son achèvement. Dans l'analyse des processus, la comparaison des Start Time et End Time pour les activités permet le calcul du temps de traitement. Cela aide à distinguer le temps de travail actif (temps de traitement) du temps d'inactivité (temps d'attente entre les activités), offrant une vue plus détaillée de l'efficacité du processus. Pourquoi c'est important Permet le calcul des temps de traitement précis des activités, aidant à différencier le temps de travail actif du temps d'attente inactif dans le processus. Où obtenir Pour certaines activités, il peut s'agir d'un champ d'horodatage séparé dans le système source. Pour d'autres, il peut être nécessaire de le déduire de l'heure de début de l'activité suivante. Exemples 2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z | |||
| Montant payé PaidAmount | La valeur monétaire totale reçue du payeur et du patient pour les services facturés. | ||
| Description Le Paid Amount est la somme cumulative de tous les paiements enregistrés sur le compte pour un événement de facturation spécifique. Il représente l'argent effectivement collecté et est une mesure principale du succès du cycle de revenus. Dans l'analyse des processus, le suivi du Paid Amount est essentiel pour comprendre les flux de trésorerie et la performance financière globale. Il peut être utilisé pour analyser la vitesse de paiement et comparer les montants facturés aux montants collectés, en mettant en évidence les problèmes de sous-paiements ou de dettes irrécouvrables. Pourquoi c'est important Représente le montant réel des fonds collectés, ce qui est une métrique de résultat clé pour le processus de GCR et essentiel pour l'analyse des flux de trésorerie. Où obtenir Cette valeur est généralement stockée dans les tables de transactions de paiement ou résumée au niveau du compte dans Optum360. Exemples 120.001000.500.00 | |||
| Statut du compte AccountStatus | L'état actuel du compte de facturation au sein du cycle de revenus. | ||
| Description Le Statut du Compte fournit un aperçu de la situation d'un événement de facturation dans le processus global, par exemple, 'En attente du payeur', 'Entièrement payé' ou 'En recouvrement'. Cet attribut donne du contexte aux activités effectuées. Ceci est utile pour filtrer et segmenter les cas afin de se concentrer sur des parties spécifiques du processus. Par exemple, l'analyse de tous les comptes actuellement 'En recouvrement' peut aider à comprendre les facteurs et le volume de cette partie spécifique et coûteuse du processus, en supportant le tableau de bord 'Volume et Facteurs d'Activité de Recouvrement'. Pourquoi c'est important Fournit un contexte de haut niveau sur l'état actuel d'un cas, permettant le filtrage et l'analyse de populations de cas spécifiques comme celles en recouvrement. Où obtenir Ceci est généralement un champ récapitulatif sur le compte patient principal ou l'enregistrement de demande de remboursement dans Optum360. Exemples OuvertEn attente du payeurEntièrement payéeEn recouvrementClôturé | |||
| Système source SourceSystem | Le système ou l'application d'origine où les données d'événement ont été enregistrées. | ||
| Description Cet attribut identifie le système source d'où les données d'un événement particulier ont été extraites. Dans un paysage informatique complexe, les données RCM peuvent provenir de la plateforme Optum360, d'un système de dossier de santé électronique (DSE) interfacé, d'une chambre de compensation ou d'un portail patient. Comprendre le système source est utile pour la validation des données, le dépannage des problèmes d'intégration et l'analyse des variations de processus qui peuvent être causées par différents comportements du système ou pratiques de saisie des données. Pourquoi c'est important Identifie l'origine des données, ce qui est crucial pour la gouvernance des données, l'évaluation de la qualité et la compréhension des variations de processus entre les différents systèmes. Où obtenir Ceci peut être une valeur statique définie lors de l'extraction des données ou un champ dans les tables sources qui indique l'origine des données. Exemples Optum360Interface-EHRClearinghouse-APIPortail-Patient | |||
| Temps de traitement ProcessingTime | Le temps nécessaire pour achever une activité spécifique, calculé à partir de ses horodatages de début et de fin. | ||
| Description Le Temps de Traitement mesure la durée d'une activité individuelle, représentant le "temps de contact" ou le travail actif effectué. Ceci est généralement calculé comme la différence entre l'Heure de Fin et l'Heure de Début d'une activité. Cette métrique calculée est cruciale pour distinguer le temps passé à travailler activement sur une tâche du temps passé à attendre l'étape suivante. Dans l'analyse des goulets d'étranglement, la compréhension des temps de traitement aide à déterminer si un retard est dû à une longue tâche ou à une longue file d'attente, conduisant à des améliorations de processus plus efficaces. Pourquoi c'est important Mesure le "temps de contact" actif pour les activités, aidant à distinguer le travail à valeur ajoutée du temps d'attente inutile dans l'analyse des goulets d'étranglement. Où obtenir Ceci est calculé en soustrayant le 'EventTime' (StartTime) du 'EndTime' pour un enregistrement d'activité donné. Exemples 15 minutes2 heures1 jour 4 heures | |||
| Utilisateur User | L'identifiant de l'utilisateur ou de l'agent système qui a effectué l'activité. | ||
| Description L'attribut User identifie la personne, l'équipe ou le bot automatisé spécifique responsable de l'exécution d'une activité donnée. Cela permet une analyse des performances au niveau individuel ou de groupe. Comprendre quel user ou quelle équipe a effectué une action est précieux pour évaluer la productivité, la qualité et le respect des procédures standard. Cela peut aider à identifier les besoins en formation ou à reconnaître les individus et les équipes très performants. Cela aide également à distinguer les tâches effectuées manuellement de celles gérées par l'automatisation. Pourquoi c'est important Attribue la responsabilité des étapes du processus et permet l'analyse des performances par individu ou par équipe, ce qui est essentiel pour la gestion des ressources et la formation. Où obtenir Les ID utilisateur sont généralement capturés dans les audit logs ou l'historique des transactions pour les enregistrements dans Optum360. Exemples j.doem.smithAutoBillerBots.jones | |||
Activités de Gestion du Cycle de Revenus
| Activité | Description | ||
|---|---|---|---|
| Avis de Virement Reçu | Le système a reçu un fichier d'avis de virement électronique (ERA) du payeur, détaillant les paiements, les ajustements et les refus. Il s'agit d'un événement explicite capturé lorsque le système ingère un fichier EDI 835. | ||
| Pourquoi c'est important Cette activité est un jalon clé indiquant que le payeur a traité la demande de remboursement. Le contenu de ce fichier dicte toutes les actions ultérieures, telles que l'enregistrement du paiement ou la gestion des refus. Où obtenir Enregistré dans les journaux de transactions EDI pour les fichiers ANSI 835 entrants. L'horodatage reflète le moment où le fichier a été reçu et traité par le système. Capture Horodatage associé à l'ingestion du fichier EDI 835 (avis de virement électronique). Type d'événement explicit | |||
| Compte clos | L'événement de facturation est considéré comme terminé, avec un solde nul et aucune autre activité attendue. Cet événement est déduit lorsque le solde du compte devient nul et que le statut du compte est mis à jour vers « Fermé » ou un état final similaire. | ||
| Pourquoi c'est important C'est l'événement de fin principal du processus. La mesure du temps de cycle total jusqu'à ce point fournit une vue complète de l'efficacité globale du RCM. Où obtenir Inférencé à partir d'une combinaison du solde du compte atteignant zéro et du champ de statut du compte étant défini sur 'Clos', 'Entièrement Payé' ou un statut final équivalent. Capture L'horodatage le plus récent du dernier enregistrement de paiement qui entraîne un solde nul, ou d'un changement de statut à « Fermé ». Type d'événement inferred | |||
| Données de service reçues | Marque le début de l'événement de facturation lorsque les informations sur les services cliniques sont reçues du Dossier Médical Électronique (DME) ou d'un autre système source. Cet événement est généralement capturé via une entrée de journal explicite ou un enregistrement de transaction créé par une interface d'intégration lors de l'ingestion réussie des données. | ||
| Pourquoi c'est important C'est l'événement de début principal du cycle de revenus. L'analyse du temps entre cette activité et le charge capture est critique pour identifier les retards de données en front-end qui impactent l'ensemble du processus. Où obtenir Enregistré dans les journaux d'interface ou les tables de transactions qui gèrent les données de service patient entrantes provenant de systèmes externes comme un DME. Recherchez les horodatages des messages HL7 ou les journaux d'appels API. Capture Capturé à partir des journaux d'intégration ou des tables de transactions horodatées à la réception des données. Type d'événement explicit | |||
| Paiement comptabilisé | Un paiement reçu a été appliqué avec succès au compte patient et aux lignes de service spécifiques. Il s'agit d'une action explicite, manuelle ou automatisée, qui rapproche le paiement des charges impayées. | ||
| Pourquoi c'est important Cette activité est critique pour mesurer l'efficacité du processus de rapprochement des paiements en back-office. Les retards d'enregistrement peuvent fausser les rapports des comptes clients et retarder la clôture des comptes. Où obtenir Trouvé dans les tables de transactions de paiement. L'horodatage de la transaction pour l'action de saisie sert d'heure d'événement. Capture L'horodatage de création de l'enregistrement de transaction de paiement appliqué à une charge spécifique. Type d'événement explicit | |||
| Réclamation soumise au payeur | La demande de remboursement générée a été envoyée électroniquement au payeur d'assurance pour adjudication. Cet événement est explicitement enregistré par le module de soumission des demandes de remboursement ou l'interface de chambre de compensation lors de la transmission réussie. | ||
| Pourquoi c'est important Il s'agit d'un jalon critique qui lance le décompte des temps de réponse des payeurs. Il aide à mesurer l'efficacité du processus de soumission des demandes de remboursement et à identifier les retards de soumission. Où obtenir Trouvé dans les journaux de transactions de réclamations ou les tables de transactions EDI (Échange de Données Informatisé), traçant spécifiquement les soumissions de fichiers de réclamations 837. Recherchez un 'horodatage de soumission' ou une 'date de transmission'. Capture Horodatage du log de transaction EDI 837 indiquant une soumission réussie. Type d'événement explicit | |||
| Refus reçu | Une réclamation a été refusée par le payeur, comme indiqué dans un avis de virement reçu. Cet événement est déduit de l'analyse des données de l'avis de virement pour les codes de motif de refus spécifiques associés aux lignes de réclamation. | ||
| Pourquoi c'est important Le suivi des refus est crucial pour identifier les causes profondes des pertes de revenus et de l'inefficacité des processus. Cette activité est le point de départ de toutes les boucles de gestion des refus et de retraitement des appels. Où obtenir Inférencé à partir des données de l'Avis de Virement Électronique (EDI 835). Le système identifie les codes de motif d'ajustement de réclamation (CARCs) qui signifient un refus. Capture Inférencé par la détection de codes de refus spécifiques (CARCs/RARCs) dans les données de virement EDI 835 analysées. Type d'événement inferred | |||
| Activité de recouvrement démarrée | Le compte patient a été transféré dans un processus de recouvrement actif en raison d'un non-paiement. Cela est généralement déduit d'un changement dans la classe financière ou le statut du compte. | ||
| Pourquoi c'est important Ceci identifie les comptes nécessitant un suivi plus intensif. L'analyse de la fréquence et des facteurs de cette activité aide à améliorer les stratégies de recouvrement en front-end. Où obtenir Inférencé à partir d'un changement de statut de compte en 'Recouvrement', 'Créances irrécouvrables' ou 'Envoyé à l'agence'. La date de ce changement de statut est l'horodatage de l'événement. Capture Horodatage d'un champ de statut de compte passant à une valeur liée au recouvrement. Type d'événement inferred | |||
| Charges capturées | Représente le point où les services et fournitures facturables spécifiques sont formellement saisis dans le système de facturation. Il s'agit d'une action explicite de l'utilisateur ou du système qui crée des enregistrements de transactions de charges. | ||
| Pourquoi c'est important Cette activité est essentielle pour mesurer le charge lag, qui est le délai entre la prestation de service et l'initiation de la facturation. La réduction de ce lag accélère directement le cycle de revenus. Où obtenir Trouvé dans les tables de transactions de charges, souvent étiquetées comme tables de saisie de charges ou de lignes de service. L'horodatage de création de l'enregistrement de charge sert d'heure d'événement. Capture L'événement est l'horodatage de création d'un enregistrement dans le référentiel des charges ou la table des transactions de charges. Type d'événement explicit | |||
| Codage terminé | Indique que les codeurs médicaux ont examiné la documentation clinique et attribué les codes CPT, HCPCS et ICD appropriés. Il s'agit généralement d'un événement explicite marqué par un utilisateur ou un moteur de codage automatisé complétant la tâche de codage. | ||
| Pourquoi c'est important Le codage est un goulet d'étranglement fréquent qui peut retarder la soumission des réclamations. Suivre cette activité aide à mesurer la productivité des codeurs et à identifier les retards dans la file d'attente de codage. Où obtenir Enregistré dans un module de workflow de codage ou par un changement de statut de l'événement de facturation de 'Codage en attente' à 'Codé'. L'horodatage de ce changement de statut ou de l'achèvement de la tâche est utilisé. Capture Horodatage d'une mise à jour de statut ou d'une entrée de log lorsqu'un utilisateur ou un système finalise le codage pour la rencontre. Type d'événement explicit | |||
| Compte ajusté | Un ajustement contractuel, une radiation ou toute autre correction financière a été enregistré sur le compte. Il s'agit d'une transaction financière explicite enregistrée dans le grand livre du système. | ||
| Pourquoi c'est important Les ajustements impactent directement la réalisation des revenus. L'analyse des raisons et du calendrier des ajustements est essentielle pour identifier les problèmes liés aux barèmes tarifaires, à la contractualisation ou à la précision de la facturation. Où obtenir Situé dans la table des transactions financières, identifiable par des codes de transaction spécifiques pour les radiations ou les ajustements. La date de la transaction est l'heure de l'événement. Capture La date de transaction d'une entrée dans le grand livre financier avec un code d'ajustement spécifique. Type d'événement explicit | |||
| Paiement Reçu | Indique qu'un paiement a été reçu d'un payeur ou d'un patient, souvent enregistré dans le cadre de l'avis de virement. Cet événement peut être capturé explicitement à partir de fichiers de virement électroniques ou de journaux de réception de fonds manuels. | ||
| Pourquoi c'est important Il s'agit d'une activité fondamentale pour l'analyse des flux de trésorerie et la mesure de la vitesse de paiement. Elle sert de déclencheur au processus d'enregistrement des paiements. Où obtenir Dérivé des informations de paiement contenues dans le fichier de virement EDI 835 ou des fichiers de lockbox d'une banque. La date du chèque ou la date de traitement dans le fichier est souvent utilisée. Capture Extrait du segment BPR d'un fichier EDI 835 ou d'un fichier de lockbox bancaire. Type d'événement explicit | |||
| Recours soumis | Un recours a été officiellement soumis au payeur pour contester une réclamation refusée. Il s'agit d'une action explicite enregistrée par un utilisateur dans le module de gestion des refus ou des recours. | ||
| Pourquoi c'est important Cette activité est une étape clé du processus de recouvrement des revenus. Le suivi des soumissions d'appels et de leurs temps de cycle est vital pour comprendre l'efficacité de la stratégie de résolution des refus. Où obtenir Enregistré dans un module de suivi des recours ou comme type de transaction spécifique contre la réclamation. Recherchez un champ 'date de recours' ou 'date de nouvelle soumission'. Capture Horodatage explicite enregistré lorsqu'un utilisateur consigne la soumission d'un recours. Type d'événement explicit | |||
| Relevé patient envoyé | Un relevé de facturation a été généré et envoyé au patient pour sa part de la facture. Il s'agit d'un événement explicite enregistré par le module de facturation patient lors de la création du relevé. | ||
| Pourquoi c'est important Cette activité initie la partie paiement direct du patient du cycle de revenus. Le suivi de cela aide à analyser l'efficacité et l'efficience du recouvrement auprès des patients. Où obtenir Enregistré dans une table d'historique de correspondance patient ou de génération de relevés. L'horodatage indique quand le relevé a été créé ou envoyé. Capture Horodatage d'un journal de génération d'état de compte patient ou d'une table d'historique. Type d'événement explicit | |||
| Reprise du refus démarrée | Un utilisateur ou un workflow automatisé a commencé le processus d'examen et de résolution d'une réclamation refusée. Cela peut être capturé explicitement par une action de l'utilisateur ou déduit d'un changement de statut de la réclamation. | ||
| Pourquoi c'est important Cette activité initie la boucle de retraitement pour les refus. Mesurer le temps entre la réception du refus et le début du retraitement aide à identifier les retards dans la file d'attente de gestion des refus. Où obtenir Trouvé dans les modules de gestion des refus ou de files d'attente de travail. Il peut s'agir d'un horodatage explicite lorsqu'un utilisateur 'ouvre' ou 'réclame' une tâche de refus, ou déduit d'un changement de statut comme 'Refusé' à 'En Reprise'. Capture Inférencé à partir d'un changement de statut de réclamation en 'Reprise' ou 'En Examen', ou d'un journal d'actions utilisateur explicite. Type d'événement inferred | |||
| Sinistre créé | Une réclamation facturable a été générée par le système, compilant toutes les charges, les codes et les informations démographiques dans un format standardisé. Il s'agit d'un événement explicite généré par le système avec un horodatage de création correspondant. | ||
| Pourquoi c'est important Cette activité marque la transition du charge capture vers le processus de facturation formel. C'est un préalable à la soumission et elle est cruciale pour le suivi des temps de traitement internes. Où obtenir Situé dans la table des réclamations ou le journal des transactions. L'horodatage de création de l'enregistrement d'en-tête de réclamation signifie l'événement. Capture Capturé à partir de l'horodatage de création de l'enregistrement principal dans la table de la base de données des réclamations. Type d'événement explicit | |||
Guides d'extraction
Les méthodes d'extraction pour ce processus sont en cours de validation. Veuillez revenir plus tard ou contactez-nous pour obtenir de l'aide.