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

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

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

Ce modèle vous guide dans la collecte des données nécessaires à l’analyse de votre processus de gestion du cycle de revenus. Il présente les attributs essentiels à recueillir, les principales activités à suivre et des conseils pratiques pour extraire ces informations. En le suivant, vous pourrez préparer vos données pour réaliser des analyses pertinentes avec le Process Mining.
  • Attributs recommandés à recueillir
  • Activités clés à suivre
  • Conseils pour l’extraction
Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Attributs de la gestion du cycle de revenus

Voici les champs de données recommandés pour votre journal d’événements afin de réaliser une analyse complète de la gestion du cycle de revenus.
3 Obligatoire 6 Recommandé 10 Facultatif
Nom Description
Événement de facturation
BillingEvent
Identifiant unique d’une prestation ou d’un produit livré donnant lieu à des frais, utilisé comme ID de cas principal.
Description

L’événement de facturation sert d’identifiant de cas principal et relie toutes les activités associées à une prestation ou à un produit livré donnant lieu à des frais. Il permet de suivre l’ensemble du cycle de génération et de recouvrement des revenus pour chaque produit ou service facturable.

En 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 différences de traitement entre les demandes de remboursement et les factures.

Pourquoi est-ce important ?

Il s’agit de l’ID de cas essentiel qui relie toutes les activités du cycle de gestion des revenus et permet d’analyser le processus de bout en bout.

Où trouver ces données

Il s’agit de la clé primaire qui relie les enregistrements des principales tables de facturation et de demandes de remboursement d’Optum360. Consultez la documentation 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 quand une activité ou un événement précis 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 réalisation. Ces données temporelles permettent de reconstituer l’ordre chronologique des événements pour chaque cas.

L’analyse utilise l’heure de l’événement pour calculer les temps de cycle entre les activités, mesurer la durée des cas et repérer les goulots d’étranglement où les attentes sont longues. Elle est indispensable à toute analyse temporelle des processus et à la mesure de leur performance.

Pourquoi est-ce important ?

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

Où trouver ces données

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 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 précise survenue dans le processus de gestion du cycle de revenus.
Description

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

L’analyse de la séquence et de la fréquence des activités permet de visualiser le flux réel du processus, de repérer les écarts par rapport à la procédure standard et de localiser les boucles de reprises fréquentes. Elle aide à comprendre les inefficacités du processus et les problèmes de conformité.

Pourquoi est-ce important ?

Cet attribut définit les étapes du processus. Il constitue la base de la cartographie du processus et permet toutes les analyses des flux.

Où trouver ces données

Cette valeur est généralement extraite des journaux d’événements, des enregistrements de changements de statut ou des codes de transaction spécifiques dans les tables opérationnelles d’Optum360.

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

Lorsqu’un payeur refuse une demande de remboursement, il fournit un code de motif de refus qui explique le problème, par exemple « Prestation non couverte » ou « Demande en double ». Ces codes sont essentiels pour comprendre les causes des retards de revenus et des reprises.

Leur analyse aide l’équipe de gestion des refus à établir ses priorités, à repérer les tendances et à mettre en place des mesures correctives. Par exemple, des refus fréquents pour « Informations manquantes » peuvent révéler un problème dans la création des demandes. Cette analyse contribue directement à réduire le taux de refus et à accélérer les encaissements.

Pourquoi est-ce important ?

Indique la cause des refus de demandes et permet de cibler les mesures préventives pour éviter de nouveaux refus et limiter les reprises coûteuses.

Où trouver ces données

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

Exemples
CO-16 : Informations manquantes dans la demande ou la prestationPR-97 : La prestation est incluse dans le paiement ou le montant autorisé d’une autre prestation ou procédureOA-18 : Demande ou prestation 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 celui-ci.

Les analystes peuvent utiliser cet identifiant pour étudier des tendances propres à certains patients, comme les réadmissions fréquentes ou les refus répétés de demandes de remboursement. Il permet également de segmenter le processus selon les données démographiques ou les antécédents des patients, afin de repérer des pistes d’amélioration de leur expérience financière.

Pourquoi est-ce important ?

Permet une analyse centrée sur le patient, afin de comprendre son parcours financier de bout en bout et de repérer des tendances propres à certaines populations de patients.

Où trouver ces données

Cet identifiant est un champ essentiel des données de référence sur les patients et des tables de transactions d’Optum360. Consultez la documentation Optum360 pour en savoir plus.

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

L’identifiant du payeur désigne la compagnie d’assurance, le programme public comme Medicare ou Medicaid, ou toute autre entité chargée de régler la demande. Chaque payeur applique souvent ses propres règles, exigences de soumission et modalités de paiement.

L’analyse du processus par identifiant du payeur est essentielle à la gestion du cycle de revenus (RCM). Elle permet de repérer les payeurs dont les délais de paiement sont les plus longs, les taux de refus les plus élevés ou les procédures de recours les plus complexes. Les services de facturation peuvent ainsi adapter leur approche à chaque payeur, accélérer les encaissements et réduire la charge administrative.

Pourquoi est-ce important ?

La segmentation du processus par payeur permet de repérer ceux qui entraînent des retards ou des refus et de cibler les améliorations de leur gestion.

Où trouver ces données

Ces informations sont enregistrées dans chaque dossier de demande de remboursement 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
Montant des abandons de créance, des ajustements contractuels ou des 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 abandons de créance. Il s’agit d’une réduction directe des revenus.

Cet attribut est essentiel au Dashboard « Incidence des ajustements de revenus » et à l’indicateur « Taux d’ajustement des revenus ». L’analyse des ajustements permet de mesurer l’incidence financière des contrats avec les payeurs et de repérer des moyens de limiter les pertes de revenus grâce à une facturation plus précise ou à la négociation des contrats.

Pourquoi est-ce important ?

Mesure directement les pertes de revenus. Il est essentiel au calcul des indicateurs financiers et à l’analyse de la rentabilité.

Où trouver ces données

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

Exemples
30.00250.2510.00
Montant facturé
BilledAmount
Montant total des frais soumis dans la demande de remboursement ou la facture.
Description

Le montant facturé correspond au montant brut des prestations fournies, avant tout paiement, ajustement ou abandon de créance. Il constitue la valeur initiale de la créance associée à l’événement de facturation.

Cet attribut est fondamental pour l’analyse financière en Process Mining. Il sert à calculer des indicateurs clés de performance (KPI), comme le taux d’ajustement des revenus, et à segmenter les cas par montant pour déterminer si les demandes de forte valeur sont traitées différemment ou subissent davantage de retards que celles de faible valeur.

Pourquoi est-ce important ?

Fournit le contexte financier de chaque cas, permet une analyse par montant et sert au calcul des principaux indicateurs financiers.

Où trouver ces données

Il s’agit d’un champ standard de chaque demande de remboursement ou compte patient dans les tables financières d’Optum360.

Exemples
150.001250.7585.50
Service de facturation
BillingDepartment
Le service ou l’équipe interne qui a géré ou effectué l’activité de facturation.
Description

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

Cet attribut est essentiel pour comparer les performances, comme le demande le Dashboard « Références de performance des services de facturation ». Il permet aux responsables de comparer l’efficacité, la rapidité et la précision des équipes, de repérer les bonnes pratiques et d’affecter les ressources là où les écarts de performance le justifient.

Pourquoi est-ce important ?

Permet de comparer les performances des équipes de facturation, de repérer celles qui obtiennent les meilleurs résultats et de cerner les points à améliorer.

Où trouver ces données

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

Exemples
Service central de facturationÉquipe de gestion des refusService de codageServices financiers aux patients
Code de prestation
ServiceCode
Code de procédure, par exemple CPT ou HCPCS, qui désigne la prestation fournie.
Description

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

L’analyse du processus par code de prestation peut révéler que certaines procédures entraînent davantage de refus, nécessitent plus de documentation ou présentent des délais de paiement plus longs. Elle permet de mieux cerner les difficultés du processus et d’adapter les règles de codage et de facturation aux différents types de prestations.

Pourquoi est-ce important ?

Permet d’analyser les processus selon le type de prestation médicale et de repérer les refus ou retards de paiement associés à certaines procédures.

Où trouver ces données

Ce code est un élément fondamental des enregistrements de saisie des frais et des détails des demandes dans Optum360.

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

L’indicateur « Correspond à une reprise » est une valeur booléenne qui signale les activités considérées comme des reprises sans valeur ajoutée, telles que « Début du traitement d’un refus » ou « Recours soumis ». Ces activités surviennent généralement lorsque le processus s’écarte de son « parcours nominal ».

Cet attribut permet de quantifier les reprises dans le processus, qui sont un signe direct d’inefficacité et de coûts. Il sert au calcul de l’indicateur « Taux de reprises dues aux erreurs de facturation » et alimente le Dashboard « Repérage des goulots d’étranglement et des boucles de reprise », en facilitant le filtrage et la visualisation de ces boucles inefficaces.

Pourquoi est-ce important ?

Aide à quantifier les inefficacités du processus en signalant les activités qui correspondent à des reprises, afin de mesurer et de réduire plus facilement les pertes.

Où trouver ces données

Cet indicateur est généralement calculé à partir de règles métier dans l’outil de Process Mining. Par exemple, toute activité qui suit un événement « Refus reçu » peut être signalée comme une reprise.

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

Cet attribut indique la date 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 précise l’ancienneté des données analysées.

Les analystes et les utilisateurs métier peuvent ainsi savoir s’ils consultent les informations les plus récentes. Cet attribut aide à tenir compte du délai de mise à jour des données et constitue une métadonnée importante pour tout projet d’analyse.

Pourquoi est-ce important ?

Précise l’ancienneté des données afin que les utilisateurs sachent à quel point l’analyse est à jour.

Où trouver ces données

Cet horodatage est généralement généré et enregistré 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
Temps de cycle total d’un événement de facturation, de la première à la dernière activité.
Description

La durée du cas mesure le temps écoulé entre le tout premier et le tout dernier événement d’un événement de facturation. Il s’agit d’un indicateur clé pour évaluer l’efficacité globale du processus.

Cette métrique alimente directement le Dashboard « Vue d’ensemble du temps de cycle RCM de bout en bout » et l’indicateur « Temps de cycle RCM moyen ». Son suivi dans le temps permet aux responsables de mesurer l’incidence des initiatives d’amélioration sur l’ensemble du cycle de revenus.

Pourquoi est-ce important ?

Représente le temps de cycle du processus de bout en bout, un indicateur clé de sa rapidité et de son efficacité globales.

Où trouver ces données

Cette durée se calcule, pour chaque ID de cas « BillingEvent » unique, en soustrayant l’horodatage du premier événement de celui du dernier.

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

L’heure de fin indique le moment où une activité s’achève. L’heure de début indique quand un événement commence, tandis que l’heure de fin permet de calculer la durée des activités dont le temps de traitement est distinct, comme le traitement d’un refus, de son démarrage à sa clôture.

Dans l’analyse des processus, la comparaison des heures de début et de fin permet de calculer la durée de traitement des activités. Vous pouvez ainsi distinguer le temps de travail effectif du temps d’attente entre les activités et mieux comprendre l’efficacité du processus.

Pourquoi est-ce important ?

Permet de calculer précisément la durée de traitement des activités et de distinguer le temps de travail effectif du temps d’attente dans le processus.

Où trouver ces données

Pour certaines activités, le système source peut comporter un champ d’horodatage distinct. Pour d’autres, l’heure de fin peut être déduite 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
Montant total reçu du payeur et du patient pour les prestations facturées.
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 sommes réellement encaissées et constitue un indicateur majeur de la performance 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 permet d’étudier la rapidité des paiements et de comparer les montants facturés aux montants encaissés, afin de repérer les sous-paiements et les créances irrécouvrables.

Pourquoi est-ce important ?

Représente les sommes réellement encaissées. Cet indicateur de résultat du processus RCM est essentiel à l’analyse des flux de trésorerie.

Où trouver ces données

Cette valeur est généralement enregistrée dans les tables des transactions de paiement ou récapitulée au niveau du compte dans Optum360.

Exemples
120.001000.500.00
Prestataire de soins
ServiceProvider
Le professionnel de santé, le service ou l’établissement qui a fourni la prestation facturable.
Description

Cet attribut désigne le prestataire concerné, par exemple un médecin, un thérapeute ou un service hospitalier, qui a fourni la prestation. Les pratiques de facturation et les habitudes de documentation peuvent varier d’un prestataire à l’autre et influer sur le cycle de revenus.

L’analyse par prestataire de soins aide à repérer les problèmes de saisie des actes, de précision du codage ou de qualité de la documentation qui surviennent au point de prise en charge. Elle peut mettre en évidence des besoins de formation des prestataires ou des pistes d’amélioration des processus, afin que les demandes soient correctement établies dès le départ.

Pourquoi est-ce important ?

Permet de remonter à l’origine des problèmes de facturation et de cibler les retours et les formations destinés au personnel soignant pour améliorer la saisie des actes et la documentation.

Où trouver ces données

Ces informations figurent dans le dossier de facturation ou de demande de remboursement d’Optum360 et sont souvent associé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 indique où en est 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 réalisées.

Il permet de filtrer et de segmenter les cas pour se concentrer sur des étapes précises du processus. Par exemple, l’analyse des comptes actuellement « En recouvrement » aide à comprendre les causes et le volume de cette étape coûteuse, et alimente le Dashboard « Volume et facteurs des activités de recouvrement ».

Pourquoi est-ce important ?

Donne une vue d’ensemble de l’état actuel d’un cas et permet de filtrer et d’analyser des groupes de cas précis, comme ceux en recouvrement.

Où trouver ces données

Il s’agit généralement d’un champ récapitulatif du compte patient principal ou du dossier de demande de remboursement dans Optum360.

Exemples
OuvertEn attente du payeurEntièrement payéEn 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 indique le système source dont proviennent les données d’un événement. Dans un environnement informatique complexe, les données RCM peuvent provenir de la plateforme Optum360, d’un dossier médical électronique (EHR) connecté, d’une chambre de compensation ou d’un portail patient.

Connaître le système source facilite la validation des données, le diagnostic des problèmes d’intégration et l’analyse des variations de processus qui peuvent découler du comportement des systèmes ou des pratiques de saisie.

Pourquoi est-ce important ?

Indique l’origine des données, une information essentielle pour leur gouvernance et l’évaluation de leur qualité, ainsi que pour comprendre les variations de processus entre les systèmes.

Où trouver ces données

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

Exemples
Optum360Interface EHRAPI de la chambre de compensationPortail patient
Utilisateur
User
Identifiant de l’utilisateur ou de l’agent système qui a effectué l’activité.
Description

L’attribut Utilisateur désigne la personne, l’équipe ou le robot automatisé responsable d’une activité. Il permet d’analyser les performances à l’échelle individuelle ou collective.

Savoir quel utilisateur ou quelle équipe a effectué une action aide à évaluer la productivité, la qualité et le respect des procédures établies. Cela peut faire ressortir des besoins de formation ou mettre en valeur les personnes et les équipes les plus performantes. L’attribut permet également de distinguer les tâches effectuées manuellement de celles prises en charge par l’automatisation.

Pourquoi est-ce important ?

Attribue la responsabilité des étapes du processus et permet d’analyser les performances par personne ou par équipe, un élément essentiel à la gestion des ressources et à la formation.

Où trouver ces données

Les identifiants des utilisateurs sont généralement consignés dans les journaux d’audit ou l’historique des transactions d’Optum360.

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

Activités de gestion du cycle de revenus

Voici les principales étapes et les jalons du processus à consigner dans votre journal d’événements pour reconstituer le processus avec précision.
6 Recommandé 9 Facultatif
Activité Description
Avis de paiement reçu
Le système a reçu du payeur un fichier électronique d’avis de paiement (ERA) détaillant les paiements, les ajustements et les refus. Cet événement explicite est enregistré lorsque le système importe un fichier EDI 835.
Pourquoi est-ce important ?

Cette activité marque une étape importante : le payeur a traité la demande de remboursement. Le contenu du fichier détermine les étapes suivantes, comme l’enregistrement du paiement ou le traitement d’un refus.

Où trouver ces données

L’événement figure dans les journaux de transactions EDI des fichiers ANSI 835 entrants. L’horodatage indique quand le système a reçu et traité le fichier.

Données à recueillir

Horodatage associé à l’importation du fichier EDI 835 (avis électronique de paiement).

Type d’événement explicit
Compte clôturé
L’événement de facturation est considéré comme terminé : le solde est nul et aucune autre activité n’est attendue. Cet événement est déduit lorsque le solde du compte atteint zéro et que son statut passe à « Closed » ou à un état final équivalent.
Pourquoi est-ce important ?

Il s’agit de l’événement de fin principal du processus. Mesurer le temps de cycle total jusqu’à cette étape donne une vue d’ensemble de l’efficacité du RCM.

Où trouver ces données

L’événement est déduit lorsque le solde du compte atteint zéro et que son statut passe à « Closed », « Paid in Full » ou à un statut final équivalent.

Données à recueillir

Horodatage le plus récent entre l’enregistrement du paiement final qui ramène le solde à zéro et le changement de statut vers « Closed ».

Type d’événement inferred
Demande de remboursement soumise au payeur
La demande de remboursement générée a été transmise par voie électronique au payeur de l’assurance pour examen. Cet événement est enregistré explicitement par le module de soumission des demandes ou l’interface de la chambre de compensation, une fois la transmission effectuée.
Pourquoi est-ce important ?

Cette étape importante marque le début du délai de réponse du payeur. Elle permet de mesurer l’efficacité du processus de soumission des demandes et de repérer les retards.

Où trouver ces données

Les informations figurent dans les journaux de transactions des demandes de remboursement ou les tables de transactions EDI (échange de données informatisé), qui suivent notamment les soumissions de fichiers de demandes 837. Recherchez un champ « submission timestamp » ou « transmit date ».

Données à recueillir

Horodatage du journal de transactions EDI 837 indiquant que la soumission a abouti.

Type d’événement explicit
Informations sur les services 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 (EHR) ou d’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’importation des données.
Pourquoi est-ce important ?

Il s’agit de l’événement de début principal du cycle de gestion des revenus. L’analyse du délai entre cette activité et la saisie des frais est essentielle pour repérer les retards de données en amont qui affectent l’ensemble du processus.

Où trouver ces données

Les informations figurent dans les journaux d’interface ou les tables de transactions qui traitent les données entrantes sur les services aux patients provenant de systèmes externes, comme un EHR. Recherchez les horodatages des messages HL7 ou les journaux d’appels API.

Données à recueillir

À extraire des journaux d’intégration ou des tables de transactions, avec l’horodatage de réception des données.

Type d’événement explicit
Paiement enregistré
Le paiement reçu a été affecté au compte du patient et aux lignes de service concernés. Cette action explicite, effectuée par un utilisateur ou automatiquement, rapproche le paiement des frais en attente.
Pourquoi est-ce important ?

Cette activité est essentielle pour mesurer l’efficacité du processus de rapprochement des paiements en back-office. Les retards d’enregistrement peuvent fausser le suivi des comptes clients et retarder la clôture des comptes.

Où trouver ces données

L’événement figure dans les tables de transactions de paiement. L’horodatage de la transaction correspondant à l’enregistrement du paiement indique l’heure de l’événement.

Données à recueillir

Horodatage de création de l’enregistrement de transaction du paiement affecté à un frais précis.

Type d’événement explicit
Refus reçu
Le payeur a refusé une demande de remboursement, comme l’indique l’avis de paiement reçu. Cet événement est déduit de l’analyse des données de l’avis de paiement, qui permet de repérer les codes de motif de refus associés aux lignes de la demande.
Pourquoi est-ce important ?

Le suivi des refus est essentiel pour repérer les causes profondes des pertes de revenus et des inefficacités des processus. Cette activité marque le début du traitement des refus et des boucles de reprises liées aux recours.

Où trouver ces données

L’événement est déduit des données de l’avis électronique de paiement (EDI 835). Le système repère les codes de motif d’ajustement de demande (CARC) qui signalent un refus.

Données à recueillir

L’événement est déduit de la détection de codes de refus précis (CARC/RARC) dans les données d’avis de paiement EDI 835 analysées.

Type d’événement inferred
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, enregistré lorsqu’un utilisateur ou un moteur de codage automatisé termine la tâche de codage.
Pourquoi est-ce important ?

Le codage constitue souvent un goulot d’étranglement qui retarde la soumission des demandes de remboursement. Le suivi de cette activité permet de mesurer la productivité des codeurs et de repérer les retards dans la file d’attente de codage.

Où trouver ces données

L’événement est enregistré dans un module de flux de travail de codage ou par un changement de statut de l’événement de facturation, de « Pending Coding » à « Coded ». L’horodatage utilisé est celui du changement de statut ou de la fin de la tâche.

Données à recueillir

Horodatage de la mise à jour du statut ou de l’entrée de journal créée lorsqu’un utilisateur ou le système finalise le codage de la rencontre.

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 est-ce important ?

Les ajustements ont une incidence directe sur les revenus réalisés. L’analyse de leurs motifs et de leur date est essentielle pour repérer les problèmes liés aux barèmes tarifaires, aux contrats ou à la précision de la facturation.

Où trouver ces données

L’événement figure dans la table des transactions financières et peut être repéré grâce aux codes de transaction associés aux radiations ou aux ajustements. La date de transaction correspond à l’heure de l’événement.

Données à recueillir

Date de transaction d’une écriture du grand livre financier portant un code d’ajustement précis.

Type d’événement explicit
Début du recouvrement
En raison d’un défaut de paiement, le compte du patient est passé en recouvrement actif. Cet événement est généralement déduit d’un changement de catégorie financière ou de statut du compte.
Pourquoi est-ce important ?

Cette activité permet de repérer les comptes qui nécessitent un suivi plus soutenu. L’analyse de sa fréquence et de ses facteurs permet d’améliorer les stratégies de recouvrement en amont.

Où trouver ces données

L’événement est 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.

Données à recueillir

Horodatage du changement du champ de statut du compte vers une valeur liée au recouvrement.

Type d’événement inferred
Début du traitement du refus
Un utilisateur ou un flux de travail automatisé a commencé à examiner et à résoudre une demande de remboursement refusée. L’événement peut être enregistré explicitement à la suite d’une action de l’utilisateur ou déduit d’un changement de statut de la demande.
Pourquoi est-ce important ?

Cette activité lance la boucle de reprise liée aux refus. Mesurer le délai entre la réception du refus et le début de son traitement permet de repérer les retards dans la file d’attente de gestion des refus.

Où trouver ces données

L’événement figure dans les modules de gestion des refus ou de file de travail. Il peut s’agir de l’horodatage explicite auquel un utilisateur « ouvre » ou « prend en charge » une tâche liée à un refus, ou d’un événement déduit d’un changement de statut, par exemple de « Denied » à « In Rework ».

Données à recueillir

L’événement est déduit d’un changement de statut de la demande vers « Rework » ou « Under Review », ou d’un journal d’action explicite de l’utilisateur.

Type d’événement inferred
Demande de remboursement créée
Le système a généré une demande de remboursement facturable en regroupant les frais, les codes et les informations démographiques dans un format normalisé. Il s’agit d’un événement explicite généré par le système, avec un horodatage de création.
Pourquoi est-ce important ?

Cette activité marque le passage de la saisie des frais au processus officiel de facturation. Elle est nécessaire à la soumission et permet de suivre les délais de traitement internes.

Où trouver ces données

L’événement figure dans la table des demandes de remboursement ou le journal des transactions. L’horodatage de création de l’enregistrement principal de la demande indique l’heure de l’événement.

Données à recueillir

À extraire de l’horodatage de création de l’enregistrement principal dans la table des demandes de remboursement.

Type d’événement explicit
Frais saisis
Indique le moment où les services et fournitures facturables sont officiellement saisis dans le système de facturation. Cette action explicite, effectuée par un utilisateur ou par le système, crée les enregistrements de transactions de frais.
Pourquoi est-ce important ?

Cette activité est essentielle pour mesurer le délai de saisie des frais, c’est-à-dire le temps écoulé entre la prestation du service et le début de la facturation. Réduire ce délai accélère directement le cycle de gestion des revenus.

Où trouver ces données

Les informations se trouvent dans les tables de transactions de frais, souvent nommées « charge entry » ou « service line ». L’horodatage de création de l’enregistrement du frais correspond à l’heure de l’événement.

Données à recueillir

L’événement correspond à l’horodatage de création d’un enregistrement dans la table des frais ou des transactions de frais.

Type d’événement explicit
Paiement reçu
Indique qu’un paiement a été reçu d’un payeur ou d’un patient. Il est souvent enregistré dans l’avis de paiement. Cet événement peut être extrait explicitement des fichiers d’avis électroniques ou des journaux manuels de réception des paiements.
Pourquoi est-ce important ?

Cette activité est fondamentale pour analyser les flux de trésorerie et mesurer la vitesse d’encaissement. Elle déclenche le processus d’enregistrement du paiement.

Où trouver ces données

À extraire des informations de paiement du fichier d’avis EDI 835 ou des fichiers de boîte postale bancaire. La date du chèque ou la date de traitement indiquée dans le fichier est souvent utilisée.

Données à recueillir

À extraire du segment BPR d’un fichier EDI 835 ou du fichier de données de boîte postale d’une banque.

Type d’événement explicit
Recours soumis
Un recours a été officiellement soumis au payeur pour contester le refus d’une demande de remboursement. Cette action explicite est enregistrée par un utilisateur dans le module de gestion des refus ou des recours.
Pourquoi est-ce important ?

Cette activité constitue une étape importante du recouvrement des revenus. Le suivi des recours soumis et de leur temps de cycle est essentiel pour évaluer l’efficacité de la stratégie de résolution des refus.

Où trouver ces données

L’événement figure dans un module de suivi des recours ou sous la forme d’un type de transaction associé à la demande. Recherchez un champ « appeal date » ou « resubmission date ».

Données à recueillir

Horodatage explicite enregistré lorsqu’un utilisateur consigne la soumission d’un recours.

Type d’événement explicit
Relevé envoyé au patient
Un relevé de facturation a été généré et envoyé au patient pour la part qui lui incombe. Cet événement explicite est enregistré par le module de facturation des patients lors de la création du relevé.
Pourquoi est-ce important ?

Cette activité marque le début de la part du cycle de gestion des revenus payée directement par le patient. Son suivi permet d’analyser l’efficacité du recouvrement auprès des patients.

Où trouver ces données

L’événement figure dans une table d’historique des communications avec les patients ou de génération des relevés. L’horodatage indique quand le relevé a été créé ou envoyé.

Données à recueillir

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

Type d’événement explicit
Recommandé Facultatif

Guides d’extraction

Comment extraire vos données d’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 modèle pour simplifier la collecte de vos données et commencer à optimiser vos processus de gestion du cycle de revenus. Repérez des pistes d’amélioration et améliorez votre efficacité en toute confiance.

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

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

Démarrez l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.