Votre template de données pour la gestion du cycle de revenus

Optum360
Votre template de données pour la gestion du cycle de revenus

Votre template de données pour la gestion du cycle de revenus

Ce template fournit une feuille de route claire pour recueillir les données nécessaires à l’analyse de votre processus de gestion du cycle de revenus. Il précise les attributs essentiels à collecter, les activités clés à suivre et les recommandations pratiques pour extraire ces informations. En suivant ce template, vous vous assurez que vos données sont prêtes pour le Process Mining.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Recommandations pour l’extraction
Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Attributs de la gestion du cycle des revenus

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète votre cycle des revenus.
3 Obligatoire 6 Recommandé 10 Facultatif
Nom Description
Événement de facturation
BillingEvent
Identifiant unique d’une prestation de service ou d’une livraison de produit générant des frais, utilisé comme Case ID principal.
Description

L’événement de facturation sert de Case ID principal et relie toutes les activités associées à une prestation de service ou à une livraison de produit générant des frais. Il permet de suivre intégralement le cycle de génération et de recouvrement du chiffre d’affaires pour chaque élément ou service facturable.

Dans le Process Mining, l’analyse par événement de facturation permet aux organisations de visualiser le parcours complet, de la prestation du service au paiement final ou à la clôture du compte. Cette vue est essentielle pour repérer les goulots d’étranglement, mesurer les temps de cycle et comprendre les variations dans le traitement des différents claims ou factures.

Pourquoi c’est important

Il s’agit du Case ID essentiel qui relie toutes les activités associées au cycle de revenus et permet d’obtenir une vue complète du processus, de bout en bout, à des fins d’analyse.

Où les obtenir

Il s’agit de la clé primaire reliant les enregistrements des tables centrales de facturation et de claims d’Optum360. Consultez la documentation d’Optum360 pour connaître les noms précis des tables et des champs.

Exemples
BE-2023-0012345BE-2023-0012346BE-2023-0012347
Heure de l’événement
EventTime
Horodatage indiquant le moment où une activité ou un événement spécifique s’est produit.
Description

L’heure de l’événement est l’horodatage associé à chaque activité. Elle indique la date et l’heure précises de sa survenue. Ces données temporelles sont essentielles pour établir la séquence chronologique des événements de chaque dossier.

Dans les analyses, l’heure de l’événement sert à calculer les temps de cycle entre les activités, à mesurer la durée des dossiers et à repérer les goulots d’étranglement où le temps d’attente est important. Elle constitue le fondement de toute analyse des processus fondée sur le temps et de toute mesure de performance.

Pourquoi c’est important

Cet horodatage est essentiel pour ordonner correctement les événements et calculer toutes les métriques fondées sur la durée, notamment les temps de cycle et les goulots d’étranglement.

Où les obtenir

Ces informations sont généralement stockées avec chaque transaction ou enregistrement de changement de statut dans les tables de la 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
Nom d’un événement ou d’une tâche spécifique survenu dans le processus de Revenue Cycle Management.
Description

Le nom de l’activité décrit une étape du processus de cycle de revenus, telle que « Claim Submitted To Payer » ou « Payment Received ». Cet attribut est fondamental pour le Process Mining, car il définit les nœuds de la carte du processus.

L’analyse de la séquence et de la fréquence des activités permet aux organisations de visualiser le flux réel du processus, de repérer les écarts par rapport à la procédure standard et d’identifier les boucles de reprise fréquentes. Cette analyse est essentielle pour comprendre les inefficacités du processus et les problèmes de conformité.

Pourquoi c’est important

Cet attribut définit les différentes étapes du processus. Il constitue la base de la carte du processus et permet toutes les analyses fondées sur les flux.

Où les obtenir

Il est généralement dérivé des journaux d’événements, des enregistrements de changement de statut ou de codes de transaction spécifiques présents dans les tables opérationnelles d’Optum360.

Exemples
Demande crééeDemande soumise au payeurPaiement reçuRejet reçuCompte clôturé
Code du motif de refus
DenialReasonCode
Code normalisé fourni par le payeur pour expliquer le refus d’un claim.
Description

Lorsqu’un payeur refuse un claim, il fournit un code du motif de refus qui explique le problème, par exemple « Service Not Covered » ou « Duplicate Claim ». Ces codes sont essentiels pour comprendre les causes profondes des retards de revenus et des reprises.

L’analyse de ces codes permet à l’équipe de gestion des refus de hiérarchiser son travail, d’identifier les tendances et de mettre en place des mesures correctives. Par exemple, une fréquence élevée de refus pour « Missing Information » peut révéler un problème dans le processus de création des claims. Cette analyse est au cœur de la réduction du taux de refus et de l’accélération des flux de trésorerie.

Pourquoi c’est important

Fournit la cause profonde des refus de claims et permet de mettre en place des interventions ciblées pour prévenir les refus futurs et réduire les reprises coûteuses.

Où les obtenir

Ce code figure dans les fichiers Electronic Remittance Advice (ERA) reçus des payeurs et est stocké dans le module de gestion des claims d’Optum360.

Exemples
CO-16 : La demande de remboursement ou le service ne contient pas les informations nécessairesPR-97 : La prestation correspondant à ce service est incluse dans le paiement ou l'abattement d'un autre service ou d'une autre procédureOA-18 : Demande de remboursement ou service en double
ID du patient
PatientId
Identifiant unique du patient ayant reçu les services.
Description

L’ID du patient est un identifiant unique attribué à chaque patient dans le système de santé. Il relie plusieurs événements de facturation à un même patient et permet une analyse centrée sur le patient.

Grâce à l’ID du patient, les analystes peuvent étudier les tendances propres à certains patients, comme les réadmissions fréquentes ou l’historique des refus de claims. Il permet également de segmenter le processus selon les caractéristiques démographiques ou l’historique des patients, ce qui peut faire apparaître des pistes importantes pour améliorer leur expérience financière.

Pourquoi c’est important

Permet une analyse centrée sur le patient, afin de comprendre son parcours financier de bout en bout et d’identifier les tendances propres à certaines populations de patients.

Où les obtenir

Cet identifiant est un champ central des données de référence des patients et des tables de transactions d’Optum360. Consultez la documentation d’Optum360 pour plus de détails.

Exemples
PAT-98765PAT-98766PAT-98767
ID du payeur
PayerId
Identifiant unique de la compagnie d’assurance ou du payeur responsable du claim.
Description

L’ID du payeur identifie précisément la compagnie d’assurance, un programme public tel que Medicare ou Medicaid, ou toute autre entité responsable du paiement du claim. Chaque payeur applique généralement ses propres règles, exigences de soumission et pratiques de paiement.

L’analyse du processus par ID du payeur est essentielle pour le RCM. Elle permet d’identifier les payeurs associés aux cycles de paiement les plus longs, aux taux de refus les plus élevés ou aux procédures d’appel les plus complexes. Ces informations permettent aux équipes de facturation d’adapter leurs stratégies à chaque payeur, d’accélérer les encaissements et de réduire la charge administrative.

Pourquoi c’est important

La segmentation du processus par payeur est essentielle pour identifier ceux qui provoquent des retards ou des refus et permettre des améliorations ciblées de la gestion des payeurs.

Où les obtenir

Ces informations sont stockées dans chaque enregistrement de claim d’Optum360. Consultez la documentation d’Optum360 pour connaître les noms des tables et des champs liés aux payeurs.

Exemples
PAYER-AETNAPAYER-BCBS-MAPAYER-MEDICAREPAYER-UHC
Montant ajusté
AdjustedAmount
Valeur monétaire des radiations, ajustements contractuels ou corrections apportés au montant facturé.
Description

Le montant ajusté correspond à la part du montant facturé qui ne devrait pas être encaissé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 du chiffre d’affaires.

Cet attribut est essentiel pour le Dashboard « Revenue Adjustment Impact » et le KPI « Revenue Adjustment Rate ». L’analyse des ajustements permet d’identifier l’impact financier des contrats avec les payeurs et de repérer les possibilités de limiter les pertes de revenus grâce à une meilleure exactitude de la facturation ou à la renégociation des contrats.

Pourquoi c’est important

Mesure directement les pertes de revenus et joue un rôle essentiel dans le calcul des KPI de performance financière et l’évaluation de la rentabilité.

Où les obtenir

Ces informations figurent dans les enregistrements de transactions d’ajustement du système financier d’Optum360.

Exemples
30.00250.2510.00
Montant facturé
BilledAmount
Valeur monétaire totale de l’ensemble des frais soumis sur le claim ou la facture.
Description

Le montant facturé correspond au montant brut des services fournis, avant tout paiement, ajustement ou radiation. Il constitue la valeur initiale de la créance pour l’événement de facturation.

Cet attribut est fondamental pour l’analyse financière dans le Process Mining. Il sert à calculer des KPI essentiels tels que le taux d’ajustement du chiffre d’affaires et permet de segmenter les dossiers selon leur valeur afin de déterminer si les claims de montant élevé sont traités différemment ou subissent davantage de retards que ceux de faible montant.

Pourquoi c’est important

Fournit le contexte financier de chaque dossier, permet une analyse fondée sur la valeur et contribue au calcul des KPI financiers essentiels.

Où les obtenir

Il s’agit d’un champ standard présent dans chaque claim ou compte patient des tables financières d’Optum360.

Exemples
150.001250.7585.50
Service de facturation
BillingDepartment
Service ou équipe interne ayant géré ou réalisé l’activité de facturation.
Description

L’attribut Service de facturation identifie l’équipe ou le domaine fonctionnel précis des opérations du cycle de revenus responsable d’une activité. Par exemple, des équipes différentes peuvent prendre en charge le codage, la soumission des claims et la gestion des refus.

Cet attribut est essentiel pour comparer les performances, comme le demande le Dashboard « Billing Department Performance Benchmarks ». Il permet à la direction de comparer l’efficacité, la rapidité et l’exactitude des différentes équipes, d’identifier les bonnes pratiques et d’allouer efficacement les ressources pour combler les écarts de performance.

Pourquoi c’est important

Permet de comparer les performances des différentes équipes de facturation, d’identifier les groupes les plus performants et de repérer les domaines à améliorer.

Où les obtenir

Cette information peut être déduite de l’utilisateur ayant exécuté la tâche ou d’un champ du compte indiquant le responsable. Consultez la documentation d’Optum360.

Exemples
Bureau central de facturationÉquipe de gestion des refusService de codageServices financiers aux patients
Code du service
ServiceCode
Code de procédure, par exemple CPT ou HCPCS, identifiant le service précis fourni.
Description

Le code du service est un code médical normalisé qui identifie précisément la procédure ou le service fourni au patient. Ces codes sont nécessaires à la facturation et déterminent en grande partie le remboursement.

L’analyse du processus par code du service peut révéler que certaines procédures sont davantage sujettes aux refus, nécessitent davantage de documentation ou présentent des cycles de paiement plus longs. Elle permet ainsi de comprendre plus finement les difficultés du processus et d’orienter les politiques de codage et de facturation pour certains types de services.

Pourquoi c’est important

Permet d’analyser le processus selon le type de service médical et de repérer les tendances de refus ou de retards de paiement propres à certaines procédures.

Où les obtenir

Ce code constitue un élément fondamental des enregistrements de saisie des frais et de détail des claims dans Optum360.

Exemples
992137104527447
Correspond à une reprise
IsRework
Indicateur précisant si une activité fait partie d’une boucle de reprise, par exemple dans la gestion des refus ou des appels.
Description

« Is Rework » est un indicateur booléen qui identifie les activités considérées comme des reprises sans valeur ajoutée, telles que « Denial Rework Started » ou « Appeal Submitted ». Ces activités surviennent généralement lorsque le processus s’écarte de son « happy path » idéal.

Cet attribut aide à quantifier les reprises dans le processus, qui constituent un indicateur direct d’inefficacité et de coût. Il sert à calculer le KPI « Billing Error Rework Rate » et alimente le Dashboard « Bottleneck Identification & Rework Loops » en facilitant le filtrage et la visualisation de ces boucles inefficaces.

Pourquoi c’est important

Aide à quantifier l’inefficacité du processus en signalant les activités correspondant à des reprises et facilite ainsi la mesure et la réduction des gaspillages.

Où les obtenir

Cette valeur est généralement dérivée à l’aide de règles métier dans l’outil de Process Mining. Par exemple, toute activité suivant un événement « Denial Received » peut être signalée comme une reprise.

Exemples
truefalse
Dernière mise à jour des données
LastDataUpdate
Horodatage de l’actualisation ou de l’extraction la plus récente des données depuis le système source.
Description

Cet attribut enregistre la date et l’heure de la dernière extraction des données depuis le système source et de leur chargement dans l’outil de Process Mining. Il fournit un contexte sur l’actualité des données analysées.

Il est important que les analystes et les utilisateurs métier sachent s’ils consultent les informations les plus récentes. Cet attribut aide à gérer les attentes concernant la latence des données et constitue un élément essentiel des métadonnées de tout projet d’analyse.

Pourquoi c’est important

Fournit un contexte important sur l’actualité des données et permet aux utilisateurs de comprendre dans quelle mesure l’analyse est à jour.

Où les obtenir

Cet horodatage est généralement généré et stocké par le processus d’extraction, de transformation et de chargement (ETL) des données.

Exemples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Durée du dossier
CaseDuration
Temps de cycle total d’un événement de facturation, de la première activité à la dernière.
Description

La durée du dossier mesure le temps total écoulé entre le tout premier événement et le tout dernier événement d’un même événement de facturation. Il s’agit d’un KPI global essentiel pour évaluer l’efficacité générale du processus.

Cette métrique alimente directement le Dashboard « RCM End-to-End Cycle Time Overview » et le KPI « Average RCM Cycle Time ». Son suivi dans le temps permet à la direction de mesurer 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 et constitue un KPI essentiel pour mesurer sa rapidité et son efficacité globales.

Où les obtenir

Cette valeur est calculée en soustrayant l’horodatage du premier événement de celui du dernier événement pour chaque Case ID « BillingEvent » unique.

Exemples
30 jours95 jours45 jours
Heure de fin
EndTime
Horodatage indiquant le moment où une activité a été terminée.
Description

L’heure de fin marque l’achèvement d’une activité. Alors que l’heure de début indique le moment où un événement s’est produit, l’heure de fin est nécessaire pour calculer la durée des activités ayant un temps de traitement distinct, comme « Denial Rework Started » et son achèvement.

Dans l’analyse des processus, la comparaison de l’heure de début et de l’heure de fin des activités permet de calculer le temps de traitement. Elle aide à distinguer le temps de travail actif du temps d’inactivité, c’est-à-dire l’attente entre les activités, et fournit ainsi une vue plus détaillée de l’efficacité du processus.

Pourquoi c’est important

Permet de calculer précisément les temps de traitement des activités et de distinguer le temps de travail actif du temps d’attente dans le processus.

Où les obtenir

Pour certaines activités, il peut s’agir d’un champ d’horodatage distinct 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
Valeur monétaire totale reçue du payeur et du patient pour les services facturés.
Description

Le montant payé correspond à la somme cumulée de tous les paiements enregistrés sur le compte pour un événement de facturation donné. Il représente les encaissements réels et constitue une mesure principale de la réussite du cycle de revenus.

Dans l’analyse des processus, le suivi du montant payé est essentiel pour comprendre les flux de trésorerie et la performance financière globale. Il peut servir à analyser la vitesse d’encaissement et à comparer les montants facturés aux montants encaissés, afin de mettre en évidence les sous-paiements ou les créances irrécouvrables.

Pourquoi c’est important

Représente les encaissements réels. Il s’agit d’un indicateur de résultat essentiel du processus de RCM et d’une donnée indispensable à l’analyse des flux de trésorerie.

Où les obtenir

Cette valeur est généralement stockée dans les tables de transactions de paiement ou agrégée au niveau du compte dans Optum360.

Exemples
120.001000.500.00
Prestataire de services
ServiceProvider
Clinicien, service ou établissement ayant fourni le service facturable.
Description

Cet attribut identifie le prestataire précis, par exemple un médecin, un thérapeute ou un service hospitalier, responsable de la prestation du service. Les différents prestataires peuvent avoir des pratiques de facturation ou des habitudes de documentation différentes, qui influent sur le cycle de revenus.

L’analyse par prestataire de services peut aider à repérer les problèmes liés à la capture des frais, à l’exactitude du codage ou à la qualité de la documentation, lorsqu’ils prennent naissance au point de prise en charge. Elle peut mettre en évidence des possibilités de formation des prestataires ou d’amélioration du processus afin de produire des claims complets dès le départ.

Pourquoi c’est important

Aide à remonter des problèmes de facturation jusqu’à leur origine et permet de fournir aux équipes cliniques un accompagnement et une formation ciblés pour améliorer la capture des frais et la documentation.

Où les obtenir

Ces informations constituent un élément clé de l’enregistrement des frais ou du claim dans Optum360 et sont souvent reliées aux données de référence des prestataires.

Exemples
Dr Emily CarterService de radiologieChirurgie généraleKinésithérapie
Statut du compte
AccountStatus
État actuel du compte de facturation dans le cycle de revenus.
Description

Le statut du compte fournit une vue instantanée de la position d’un événement de facturation dans le processus global, par exemple « Pending Payer », « Paid in Full » ou « In Collections ». Cet attribut donne du contexte aux activités en cours.

Il est utile pour filtrer et segmenter les dossiers afin de se concentrer sur certaines parties du processus. Par exemple, l’analyse de tous les comptes actuellement « In Collections » peut aider à comprendre les facteurs et le volume de cette partie coûteuse du processus, et à alimenter le Dashboard « Collection Activity Volume & Drivers ».

Pourquoi c’est important

Fournit une vue d’ensemble de l’état actuel d’un dossier et permet de filtrer et d’analyser des populations spécifiques, comme les comptes en recouvrement.

Où les obtenir

Il s’agit généralement d’un champ récapitulatif de l’enregistrement principal du compte patient ou du claim dans Optum360.

Exemples
OuvertEn attente du payeurPayé intégralementEn recouvrementClôturé
Système source
SourceSystem
Système ou application d’origine dans lequel les données de l’événement ont été enregistrées.
Description

Cet attribut identifie le système source depuis lequel les données d’un événement donné ont été extraites. Dans un environnement informatique complexe, les données de RCM peuvent provenir de la plateforme centrale Optum360, d’un système Electronic Health Record (EHR) interfacé, d’une chambre de compensation ou d’un portail patient.

La connaissance du système source est utile pour valider les données, résoudre les problèmes d’intégration et analyser les variations du processus pouvant être dues au comportement de systèmes différents ou aux pratiques de saisie des données.

Pourquoi c’est important

Identifie l’origine des données, ce qui est essentiel pour la gouvernance des données, l’évaluation de leur qualité et la compréhension des variations du processus entre les différents systèmes.

Où les obtenir

Il peut s’agir d’une valeur statique définie lors de l’extraction des données ou d’un champ des tables sources indiquant l’origine des données.

Exemples
Optum360EHR-InterfaceClearinghouse-APIPatient-Portal
Utilisateur
User
Identifiant de l’utilisateur ou de l’agent système ayant exécuté l’activité.
Description

L’attribut Utilisateur identifie la personne, l’équipe ou le bot automatisé responsable de l’exécution d’une activité donnée. Il permet d’analyser les performances au niveau individuel ou collectif.

Savoir quel utilisateur ou quelle équipe a exécuté une action est utile pour évaluer la productivité, la qualité et le respect des procédures standard. Cela peut aider à identifier les besoins de formation ou à reconnaître les personnes et les équipes les plus performantes. Cet attribut permet également de distinguer les tâches réalisées manuellement de celles prises en charge par l’automatisation.

Pourquoi c’est important

Attribue la responsabilité des étapes du processus et permet d’analyser les performances par personne ou par équipe, ce qui est essentiel pour la gestion des ressources et la formation.

Où les obtenir

Les ID utilisateur sont généralement enregistrés dans les journaux d’audit ou l’historique des transactions des enregistrements d’Optum360.

Exemples
j.doem.smithAutoBillerBots.jones
Obligatoire Recommandé Facultatif

Activités de gestion du cycle des revenus

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour une découverte précise du processus.
6 Recommandé 9 Facultatif
Activité Description
Avis de paiement reçu
Le système a reçu du payeur un fichier d'avis de paiement électronique (ERA) détaillant les paiements, les ajustements et les rejets. Il s'agit d'un événement explicite enregistré lors de l'ingestion d'un fichier EDI 835 par le système.
Pourquoi c’est important

Cette activité constitue une étape importante, car elle indique que le payeur a traité la demande. Le contenu de ce fichier détermine toutes les actions suivantes, comme l'imputation du paiement ou la gestion des rejets.

Où les obtenir

Enregistré dans les journaux de transactions EDI pour les fichiers ANSI 835 entrants. L'horodatage indique le moment où le fichier a été reçu et traité par le système.

Collecte

Horodatage associé à l'ingestion du fichier EDI 835 (Electronic Remittance Advice).

Type d’événement explicit
Compte clôturé
L’événement de facturation est considéré comme terminé, avec un solde nul et aucune activité supplémentaire prévue. Cet événement est déduit lorsque le solde du compte devient nul et que son statut est mis à jour sur « Closed » ou sur un état final similaire.
Pourquoi c’est important

Il s’agit de l’événement final principal du processus. La mesure du temps de cycle total jusqu’à ce stade fournit une vue complète de l’efficacité globale du RCM.

Où les obtenir

Déduit de la combinaison d’un solde de compte nul et de la définition du champ de statut du compte sur « Closed », « Paid in Full » ou un statut final équivalent.

Collecte

Dernier horodatage entre l’enregistrement du paiement final entraînant un solde nul et le changement de statut vers « Closed ».

Type d’événement inferred
Demande soumise au payeur
La demande générée a été envoyée électroniquement à l'assureur payeur pour traitement. Cet événement est enregistré explicitement par le module de soumission des demandes ou l'interface de la chambre de compensation après la transmission réussie.
Pourquoi c’est important

Il s'agit d'une étape essentielle qui déclenche le décompte du délai de réponse du payeur. Elle permet de mesurer l'efficacité du processus de soumission des demandes et d'identifier les retards d'envoi.

Où les obtenir

Se trouve dans les journaux de transactions des demandes ou les tables de transactions EDI (Electronic Data Interchange), qui suivent notamment les soumissions de fichiers de demandes 837. Recherchez un champ « submission timestamp » ou « transmit date ».

Collecte

Horodatage issu du journal de transactions EDI 837 indiquant la soumission réussie.

Type d’événement explicit
Données de prestation reçues
Marque le début de l'événement de facturation, lorsque les informations relatives à une prestation clinique sont reçues depuis le dossier médical électronique (EHR) ou un autre système source. Cet événement est généralement enregistré dans une entrée de journal explicite ou un enregistrement de transaction créé par une interface d'intégration après l'ingestion réussie des données.
Pourquoi c’est important

Il s'agit de l'événement de début principal du cycle de revenus. L'analyse du délai entre cette activité et la capture des charges est essentielle pour identifier les retards de données en amont qui affectent l'ensemble du processus.

Où les obtenir

Enregistré dans les journaux d'interface ou les tables de transactions qui traitent les données entrantes relatives aux prestations des patients depuis des systèmes externes comme un EHR. Recherchez les horodatages des messages HL7 ou les journaux d'appels API.

Collecte

Extrait des journaux d'intégration ou des tables de transactions horodatés lors de la réception des données.

Type d’événement explicit
Paiement imputé
Un paiement reçu a été correctement affecté au compte patient et aux lignes de prestation concernés. Il s'agit d'une action explicite effectuée par un utilisateur ou automatiquement, qui rapproche le paiement des charges en attente.
Pourquoi c’est important

Cette activité est essentielle pour mesurer l'efficacité du processus d'imputation des paiements en back-office. Les retards d'imputation peuvent fausser le reporting des créances clients et retarder la clôture des comptes.

Où les obtenir

Se trouve dans les tables de transactions de paiement. L'horodatage de la transaction d'imputation sert d'heure de l'événement.

Collecte

Horodatage de création de l'enregistrement de transaction de paiement affecté à une charge précise.

Type d’événement explicit
Rejet reçu
Une demande a été rejetée par le payeur, comme l'indique un avis de paiement reçu. Cet événement est déduit de l'analyse des données de l'avis de paiement, qui recherche les codes de motif de rejet associés aux lignes de la demande.
Pourquoi c’est important

Le suivi des rejets est essentiel pour identifier les causes profondes des pertes de revenus et des inefficacités des processus. Cette activité constitue le point de départ de toutes les boucles de gestion des rejets et de reprise liées aux recours.

Où les obtenir

Déduit des données de l'Electronic Remittance Advice (EDI 835). Le système identifie les codes de motif d'ajustement des demandes (CARC) qui signalent un rejet.

Collecte

Déduit de la détection de codes de rejet spécifiques (CARC/RARC) dans les données analysées de l'avis de paiement EDI 835.

Type d’événement inferred
Activité de recouvrement commencée
Le compte patient a été intégré à un processus actif de recouvrement en raison d’un impayé. Cette situation est généralement déduite d’une modification de la classe financière ou du statut du compte.
Pourquoi c’est important

Cela permet d’identifier les comptes nécessitant un suivi plus soutenu. L’analyse de la fréquence et des facteurs à l’origine de cette activité contribue à améliorer les stratégies de recouvrement en amont.

Où les obtenir

Déduit d’un changement de statut du compte vers « Collections », « Bad Debt » ou « Sent to Agency ». La date de ce changement de statut correspond à l’horodatage de l’événement.

Collecte

Horodatage de la modification d’un champ de statut du compte vers une valeur liée au recouvrement.

Type d’événement inferred
Charges capturées
Représente le moment où les prestations et fournitures facturables sont officiellement saisies dans le système de facturation. Il s'agit d'une action explicite effectuée par un utilisateur ou le système, qui crée des enregistrements de transactions de charges.
Pourquoi c’est important

Cette activité est essentielle pour mesurer le délai de capture des charges, c'est-à-dire le temps écoulé entre la réalisation de la prestation et le début de la facturation. Réduire ce délai accélère directement le cycle de revenus.

Où les obtenir

Se trouve dans les tables de transactions de charges, souvent nommées tables de saisie des charges ou de lignes de prestation. L'horodatage de création de l'enregistrement de charge sert d'heure de l'événement.

Collecte

L'événement correspond à l'horodatage de création d'un enregistrement dans la table de référence des charges ou dans la table des transactions de charges.

Type d’événement explicit
Codification terminée
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, enregistré par un utilisateur ou par un moteur de codification automatisé à l'issue de la tâche de codification.
Pourquoi c’est important

La codification constitue souvent un goulot d'étranglement susceptible de retarder la soumission des demandes. Le suivi de cette activité permet de mesurer la productivité des codeurs et d'identifier les retards dans la file de codification.

Où les obtenir

Enregistré dans un module de flux de travail de codage ou à la suite d’un changement de statut de l’événement de facturation, de «a0Pending Codinga0» à «a0Codeda0». L’horodatage de ce changement de statut ou de l’achèvement de la tâche est utilisé.

Collecte

Horodatage d'une mise à jour de statut ou d'une entrée de journal enregistrée lorsqu'un utilisateur ou le système finalise la codification du dossier.

Type d’événement explicit
Compte ajusté
Un ajustement contractuel, une radiation ou une autre correction financière a été enregistré sur le compte. Il s’agit d’une transaction financière explicite inscrite dans le grand livre du système.
Pourquoi c’est important

Les ajustements ont un impact direct sur la réalisation du chiffre d’affaires. L’analyse de leurs motifs et de leur calendrier est essentielle pour repérer les problèmes liés aux grilles tarifaires, aux contrats ou à l’exactitude de la facturation.

Où les obtenir

Situé dans la table des transactions financières et identifiable grâce à des codes de transaction spécifiques correspondant aux radiations ou aux ajustements. La date de transaction correspond à l’heure de l’événement.

Collecte

Date de transaction d’une entrée du grand livre financier associée à un code d’ajustement spécifique.

Type d’événement explicit
Demande créée
Une demande facturable a été générée par le système, qui rassemble 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 le passage de la capture des charges au processus formel de facturation. Elle constitue un préalable à la soumission et est essentielle au suivi des délais de traitement internes.

Où les obtenir

Se trouve dans la table des demandes ou dans le journal des transactions. L'horodatage de création de l'en-tête de la demande indique l'événement.

Collecte

Extrait de l'horodatage de création de l'enregistrement principal dans la table de la base de données des demandes.

Type d’événement explicit
Paiement reçu
Indique qu'un paiement a été reçu d'un payeur ou d'un patient, souvent dans le cadre de l'avis de paiement. Cet événement peut être capturé explicitement à partir de fichiers de paiement électroniques ou de journaux manuels de réception des fonds.
Pourquoi c’est important

Il s'agit d'une activité fondamentale pour analyser la trésorerie et mesurer la vitesse d'encaissement. Elle déclenche le processus d'imputation du paiement.

Où les obtenir

Dérivé des informations de paiement contenues dans le fichier de paiement EDI 835 ou dans les fichiers de lockbox d'une banque. La date du chèque ou la date de traitement indiquée dans le fichier est souvent utilisée.

Collecte

Extrait du segment BPR d'un fichier EDI 835 ou du fichier de données lockbox d'une banque.

Type d’événement explicit
Recours soumis
Un recours a été officiellement soumis au payeur pour contester une demande rejetée. Il s'agit d'une action explicite enregistrée par un utilisateur dans le module de gestion des rejets ou des recours.
Pourquoi c’est important

Cette activité constitue une étape importante du processus de recouvrement des revenus. Le suivi des soumissions de recours et de leurs délais de traitement est essentiel pour évaluer l'efficacité de la stratégie de résolution des rejets.

Où les obtenir

Enregistré dans un module de suivi des recours ou comme type de transaction spécifique associé à la demande. Recherchez un champ « appeal date » ou « resubmission date ».

Collecte

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 la part restant à sa charge. 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é lance la partie du cycle de revenus financée directement par le patient. Son suivi permet d'analyser l'efficacité et la performance du recouvrement auprès des patients.

Où les obtenir

Enregistré dans une table d'historique de la correspondance avec les patients ou de la génération des relevés. L'horodatage indique le moment où le relevé a été créé ou envoyé.

Collecte

Horodatage issu d'un journal ou d'une table d'historique de génération des relevés patients.

Type d’événement explicit
Reprise d'un rejet commencée
Un utilisateur ou un flux de travail automatisé a commencé l’examen et la résolution d’une demande de remboursement refusée. Cette activité peut être enregistrée explicitement par une action de l’utilisateur ou déduite d’un changement de statut de la demande.
Pourquoi c’est important

Cette activité lance la boucle de reprise liée aux rejets. Mesurer le délai entre la réception du rejet et le début de la reprise permet d'identifier les retards dans la file de gestion des rejets.

Où les obtenir

Se trouve dans les modules de gestion des rejets ou de file de travail. Il peut s'agir d'un horodatage explicite enregistré lorsqu'un utilisateur « ouvre » ou « prend en charge » une tâche de rejet, ou d'un événement déduit d'un changement de statut tel que « Denied » vers « In Rework ».

Collecte

Déduit d'un changement de statut de la demande vers « Rework » ou « Under Review », ou d'un journal d'action utilisateur explicite.

Type d’événement inferred
Recommandé Facultatif

Guides d’extraction

Comment obtenir vos données depuis Optum360

Les méthodes d’extraction de ce processus sont en cours de validation. Revenez plus tard ou contactez-nous pour obtenir de l’assistance.

Prêt à commencer ?

Utilisez ce template pour simplifier la collecte de vos données et commencer à optimiser vos processus de gestion du cycle de revenus. Obtenez des analyses utiles et atteignez un niveau d’efficacité optimal en toute confiance.

Optimisez la gestion du cycle de revenus et réduisez les délais dès aujourd’hui

Rejoignez les organisations qui ont réduit leur temps de cycle de 30 % et amélioré leur santé financière.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.