Votre Modèle de Données de Gestion du cycle de revenus (RCM)
Votre Modèle de Données de Gestion du cycle de revenus (RCM)
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction pour le cycle de revenus Oracle Health
Attributs de Gestion du cycle de revenus (RCM)
| Nom | Descriptionn | ||
|---|---|---|---|
| Événement de facturation BillingEvent | L'identifiant unique pour la livraison d'un service ou produit générant une charge, servant d'identifiant de cas pour le processus du cycle de revenus. | ||
| Descriptionn L'Événement de Facturation agit comme l'identifiant de dossier principal, reliant toutes les activités, de la saisie des frais à la clôture du compte, pour un élément facturable distinct. Chaque Événement de Facturation représente une instance unique du processus du cycle de revenus, permettant un suivi complet de son parcours à travers diverses étapes comme la soumission des réclamations, l'enregistrement des paiements, et les rejets ou ajustements potentiels. Dans l'analyse Process Mining, cet attribut est indispensable pour reconstituer le flux de processus complet. Il facilite la visualisation des variantes de processus, le calcul des temps de cycle entre les activités et l'identification des points de blocage ou des écarts associés à des événements de facturation spécifiques. Pourquoi est-ce important ? : C'est la clé essentielle pour suivre l'ensemble du cycle de vie d'un service facturable, permettant toute analyse de flux de processus et mesure de performance. Source des données : Cet identifiant doit être une clé unique présente dans les tables de transactions de facturation ou de frais principales au sein d'Oracle Health Revenue Cycle. Consultez la documentation du système pour identifier la clé primaire des événements de frais. Exemples BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Horodatage de l'événement EventTimestamp | La date et l'heure précises auxquelles une activité a été enregistrée dans le système. | ||
| Descriptionn Cet attribut fournit l'horodatage pour chaque activité, marquant le moment exact où elle s'est produite. Il est indispensable pour comprendre le timing et la séquence des événements au sein du cycle de revenus pour un événement de facturation spécifique. En analyse, l'horodatage de l'événement est utilisé pour ordonner les activités chronologiquement, calculer les durées et les temps de cycle entre les différentes étapes, et effectuer une analyse des points de blocage. Il est la base de toutes les métriques Process Mining temporelles, telles que l'identification des délais entre « Réclamation soumise » et « Remise reçue ». Pourquoi est-ce important ? : Cet horodatage est indispensable pour l'ordonnancement des événements, le calcul de toutes les métriques de performance comme les temps de cycle et les durées, et l'identification des points de blocage du processus. Source des données : Chaque table de journal des transactions ou des événements dans le cycle de revenus Oracle Health doit avoir une colonne Exemples 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Nom de l'activité ActivityName | Le nom de l'étape ou de l'événement spécifique survenu au sein du processus du cycle de revenus. | ||
| Descriptionn Cet attribut enregistre le nom de chaque activité réalisée au cours du cycle de vie d'un événement de facturation. Les exemples incluent « Frais saisis », « Réclamation soumise au payeur » et « Paiement enregistré ». Ces activités forment les nœuds de la carte de processus découverte. L'analyse de la séquence et de la fréquence des activités constitue le fondement du Process Mining. Cet attribut aide à identifier les chemins de processus les plus courants, à découvrir les écarts par rapport à la procédure standard et à comprendre le flux opérationnel du cycle de revenus. Pourquoi est-ce important ? : Il définit les étapes du processus, pour visualiser de la cartographie des processus et l'analyse des modèles de workflow. Source des données : Généralement dérivé des journaux d'événements, des enregistrements de changement de statut ou de tables de transactions spécifiques associées aux différentes étapes du cycle de revenus dans Oracle Health. Exemples Réclamation généréeRemise reçueRefus contestéCompte clos | |||
| Catégorie de patient PatientClass | La classification de la rencontre patient, telle que hospitalisation ou ambulatoire. | ||
| Descriptionn Cet attribut catégorise le type de visite ou de rencontre patient qui a généré le frais. Les classifications courantes incluent Hospitalisation, Ambulatoire, Urgence et Patient récurrent. La classe de patient dicte souvent l'ensemble du processus de facturation et de soumission des réclamations. Les différentes classes de patients suivent des parcours de processus distincts et ont des exigences de conformité différentes. L'analyse du processus basée sur cet attribut aide à comprendre ces variations, à adapter les initiatives d'amélioration et à garantir que les procédures correctes sont suivies pour chaque classe. Pourquoi est-ce important ? : Sépare les flux de processus distincts (par exemple, hospitalisation vs. ambulatoire) qui présentent des complexités, des délais et des exigences de facturation différents. Source des données : Ceci est un champ standard associé à un enregistrement de rencontre patient ou d'admission dans Oracle Health. Exemples Patient hospitaliséPatient ambulatoireUrgenceRécurrent | |||
| Code de motif de refus DenialReasonCode | Un code standardisé indiquant la raison pour laquelle une réclamation a été refusée par le payeur. | ||
| Descriptionn Lorsqu'un payeur refuse une réclamation, il fournit un code de motif expliquant le refus, tel que « Service non couvert » ou « Réclamation en double ». Cet attribut saisit ce code et sa description associée. L'analyse des motifs de refus est clée pour améliorer le cycle de revenus. Elle permet à l'organisation d'identifier les schémas courants, tels que des problèmes de codage ou d'éligibilité du patient, et de mettre en œuvre des actions correctives pour prévenir les refus futurs. Cela a un impact direct sur le taux de réclamations sans erreur et réduit le coût du reprises. Pourquoi est-ce important ? : Fournit la cause profonde des refus de réclamations, permettant des améliorations ciblées pour augmenter le taux de réclamations propres et accélérer le recouvrement des revenus. Source des données : Ces informationsns sont reçues dans l'avis de remise électronique (fichier ANSI 835) du payeur et doivent être stockées dans les tables de réclamations ou de remises d'Oracle Health. Exemples CO-16 : La réclamation/le service manque d'informations nécessaires à l'arbitrage.PR-96 : Charge(s) non couverte(s).CO-18 : Réclamation/service en double. | |||
| Montant de l'ajustement AdjustmentAmount | La valeur monétaire de tout ajustement apporté au solde du compte. | ||
| Descriptionn Cet attribut saisit le montant de tout ajustement financier, tel que les allocations contractuelles, les amortissements ou les corrections, appliqués à l'événement de facturation. Les ajustements réduisent directement les revenus attendus d'une charge. Le tableau de bord « Impact des ajustements de compte » repose fortement sur cet attribut. L'analyse des montants d'ajustement et de leurs raisons associées aide à identifier les sources de fuite de revenus, les problèmes de gestion de contrat ou les problèmes dans le processus initial de saisie des frais. C'est un indicateur clé pour la santé financière. Pourquoi est-ce important ? : Quantifie les fuites de revenus dues aux amortissements ou aux corrections, aidant à identifier et à traiter les causes profondes de l'érosion financière. Source des données : Trouvé dans les tables de transactions financières qui enregistrent les ajustements ou les amortissements par rapport à un compte patient. Exemples -50.25-120.0025.00 | |||
| Nom du payeur PayerName | Le nom de la compagnie d'assurance ou du payeur tiers responsable du paiement. | ||
| Descriptionn Cet attribut identifie l'entité, telle qu'une compagnie d'assurance ou un programme gouvernemental comme Medicare, qui est facturée pour le service. L'information sur le payeur est clée pour l'analyse du cycle de revenus. L'analyse du processus par payeur peut révéler des variations significatives dans les délais de paiement, les taux de refus et les taux de réussite des appels. Elle aide à identifier les payeurs problématiques qui causent des retards ou des pertes de revenus et est indispensablele pour gérer efficacement les contrats et les relations avec les payeurs. Pourquoi est-ce important ? : Permet la segmentation du processus par payeur, révélant différents comportements, taux de refus et vitesses de paiement, ce qui est impératif pour la performance financière. Source des données : Ces informationsns sont stockées dans les dossiers de facturation ou d'assurance du patient au sein d'Oracle Health Revenue Cycle. Exemples AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Service de facturation BillingDepartment | Le département ou l'équipe fonctionnelle responsable de l'activité. | ||
| Descriptionn Cet attribut spécifie le département, tel que « Saisie des frais », « Codage » ou « Recouvrement », qui a effectué l'activité. Il fournit un contexte organisationnel au flux de processus. L'analyse du processus d'un point de vue départemental est indispensablele pour comprendre les transferts entre les équipes et identifier les inefficacités transversales. Elle soutient le tableau de bord « Charge de travail du service de facturation » en permettant l'agrégation des activités et des métriques de performance au niveau du département. Pourquoi est-ce important ? : Assigne les activités aux unités organisationnelles, ce qui est indispensable pour analyser les transferts interdépartementaux, la charge de travail et la performance des équipes. Source des données : Ces informationsns peuvent être stockées directement avec les données de profil utilisateur dans Oracle Health ou dérivées en fonction de l'utilisateur ou du type d'activité. Exemples Accès patientCodageFacturationRecouvrement | |||
| Solde impayé OutstandingBalance | Le solde impayé restant pour l'événement de facturation à un moment donné. | ||
| Descriptionn Cet attribut indique le montant impayé actuel dû pour un événement de facturation après l'application de tous les paiements et ajustements. Il représente les comptes débiteurs actifs pour cette charge spécifique. C'est un attribut critique pour le tableau de bord « Ancienneté du solde impayé ». L'analyse de cette valeur au fil du temps aide à surveiller la vitesse des flux de trésorerie, à évaluer l'efficacité des efforts de recouvrement et à calculer les KPI financiers clés comme les Jours de Vente en Cours (JVC). Pourquoi est-ce important ? : Suit les comptes débiteurs actuels pour chaque cas, ce qui est indispensable pour gérer les flux de trésorerie et analyser l'efficacité des recouvrements. Source des données : Cette valeur est généralement calculée à partir de la somme de toutes les transactions financières (frais, paiements, ajustements) pour un événement de facturation donné. Elle peut exister en tant que champ dans une table récapitulative de compte. Exemples 75.000.00550.80 | |||
| Utilisateur UserPerformingAction | L'identifiant ou le nom de l'utilisateur qui a effectué l'activité. | ||
| Descriptionn Cet attribut identifie l'employé ou l'utilisateur du système automatisé responsable de l'exécution d'une activité spécifique dans le processus. Il est impératif pour comprendre la répartition de la charge de travail, la performance des ressources et l'identification des besoins en formation. En analyse, cet attribut permet de filtrer la cartographie des processus par utilisateur ou équipe, de comparer les performances entre différentes ressources et d'analyser la charge de travail pour le tableau de bord « Charge de travail du service de facturation ». Il peut aider à identifier les meilleurs collaborateurs les plus performants ou les individus qui pourraient nécessiter un soutien ou une formation supplémentaire. Pourquoi est-ce important ? : Relie les activités de processus à des utilisateurs ou des équipes spécifiques, permettant l'analyse de la charge de travail, la comparaison des performances et l'identification des opportunités de formation. Source des données : Les champs d'ID utilisateur (par exemple, 'CREATED_BY', 'USER_ID') sont généralement présents dans les tables de transactions des modules Oracle Health. Exemples j.doeasmithBillingBot_AUTOk.williams | |||
| Dernière mise à jour des données LastDataUpdate | L'horodatage indiquant la dernière fois que les données de cet événement ont été actualisées ou extraites. | ||
| Descriptionn Cet attribut indique la dernière mise à jour du jeu de données. Il fournit un contexte sur la la réactualisation des données analysées, ce qui est important pour comprendre la pertinence des informations dérivées de l'analyse Process Mining. Les utilisateurs peuvent vérifier cet attribut pour confirmer qu'ils consultent les analyses de vos processus les plus récentes. Il aide à gérer les attentes concernant la récence des données et est un élément clé de la gouvernance des données et de l'assurance qualité. Pourquoi est-ce important ? : Indique la la réactualisation des données, garantissant que l'analyse et les décisions sont basées sur des informations à jour. Source des données : Ceci est un champ de métadonnées généralement généré et rempli pendant le processus ETL qui charge les données dans la plateforme Process Mining. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Est Automatisé IsAutomated | Un indicateur signalant si l'activité a été effectuée par un système automatisé ou par un utilisateur humain. | ||
| Descriptionn Cet attribut booléen distingue les activités exécutées par l'automatisation logicielle, telles que les bots ou les tâches par lots système, de celles effectuées manuellement par un utilisateur. Par exemple, « Réclamation générée » pourrait être une étape automatisée, tandis que « Refus contesté » est probablement manuel. L'analyse de cet attribut aide à comprendre le niveau d'automatisation dans le processus et son impact sur l'efficacité et les taux d'erreur. Il peut être utilisé pour comparer la performance des parcours automatisés et manuels et identifier les opportunités d'automatisation supplémentaire. Pourquoi est-ce important ? : Différencie les activités humaines des activités automatisées, ce qui est indispensable pour analyser l'efficacité de l'automatisation et identifier de nouvelles opportunités d'automatisation. Source des données : Ceci est généralement dérivé en fonction de l'attribut UserPerformingAction. Par exemple, les activités effectuées par des identifiants utilisateur comme 'SYSTEM' ou 'RPA_BOT' sont signalées comme automatisées. Exemples truefaux | |||
| Est un reprises IsRework | Un indicateur qui identifie les activités représentant un reprises ou un effort répété. | ||
| Descriptionn Cet attribut calculé signale les activités qui indiquent une déviation par rapport au « chemin idéal » et constituent un reprises. Par exemple : « Réclamation corrigée soumise » ou « Refus contesté », qui ne se produiraient pas si le processus s'était déroulé parfaitement du premier coup. L'identification et la quantification du reprises sont un objectif clé du Process Mining. Ce marqueur permet de filtrer et d'analyser facilement toutes les boucles de reprise, aidant à mesurer la fréquence, le coût et les causes des inefficacités de processus. Il est indispensable pour comprendre le coût réel de la qualité dans le cycle de revenus. Pourquoi est-ce important ? : Aide à quantifier la fréquence et l'impact des boucles de reprise, mettant en évidence les inefficacités de processus et le coût de la mauvaise qualité. Source des données : Ceci est un attribut dérivé. Il est calculé lors de la transformation des données en appliquant une logique métier qui marque les noms d'activités spécifiques comme du reprises. Exemples truefaux | |||
| Heure de fin de l'événement EventEndTime | L'horodatage marquant la fin d'une activité, si disponible. | ||
| Descriptionn Alors que StartTime marque le début d'une activité, (EventEndTime) en marque la conclusion. Toutes les activités n'ont pas une heure de fin distincte, car beaucoup sont des événements instantanés. Cependant, pour les activités qui ont une durée, comme « Refus contesté » qui pourrait prendre du temps à traiter, ce champ est très utile. Cet attribut permet un calcul plus précis du temps de traitement pour les activités individuelles. Il aide à différencier le temps d'attente (temps entre les activités) et le temps de traitement (temps passé sur une activité). Pourquoi est-ce important ? : Permet le calcul direct du temps nécessaire à la fin d'une activité, en séparant le temps de traitement du temps d'attente. Source des données : Certaines tables de transactions dans Oracle Health Revenue Cycle peuvent contenir à la fois un horodatage de début et de fin pour des tâches spécifiques et de longue durée. Exemples 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| ID du patient PatientId | L'identifiant unique du patient associé à l'événement de facturation. | ||
| Descriptionn Cet attribut est l'identifiant unique du patient ayant reçu le service, souvent appelé Numéro de Dossier Médical (NDM). Il relie la transaction financière à un individu spécifique. Bien que n'étant pas l'ID de cas pour le processus, l'ID Patient est utile pour agréger tous les événements de facturation pour un seul patient afin de comprendre l'ensemble de son parcours financier. Il permet également la segmentation basée sur les données démographiques ou l l'historique du patient si jointes aux données de référence du patient. Pourquoi est-ce important ? : Relie les événements financiers à un patient spécifique, permettant une analyse centrée sur le patient et l'agrégation de toutes ses activités de facturation. Source des données : Cet identifiant est un élément central du dossier patient principal et sera présent dans toutes les tables de transactions connexes comme les frais, les réclamations et les paiements. Exemples MRN-1002345MRN-1002346MRN-1002347 | |||
| Montant de la charge ChargeAmount | La valeur monétaire brute du service ou produit facturé. | ||
| Descriptionn Cet attribut représente le montant initial non escompté facturé pour un service avant l'application de tout ajustement, allocation contractuelle ou paiement. C'est la valeur financière de départ pour l'événement de facturation. Le suivi du montant facturé est impératif pour l'analyse financière, comme le calcul de la valeur totale des services rendus et la compréhension de l'impact financier des ajustements ou amortissements ultérieurs. Il sert de référence pour mesurer la réalisation des revenus. Pourquoi est-ce important ? : Établit la valeur financière initiale du cas, ce qui est indispensable pour toutes les analyses financières et évaluations d'impact ultérieures. Source des données : Situé dans les tables de détails de charge ou de transactions de charge dans Oracle Health. Exemples 150.001250.7585.50 | |||
| Motif du Litige DisputeReason | La raison fournie par le client ou le patient pour contester une facture ou un frais. | ||
| Descriptionn Cet attribut saisit la raison pour laquelle un patient ou une autre partie responsable a contesté une facture. Les raisons peuvent inclure des frais incorrects, des services non rendus ou des problèmes de traitement d'assurance. Ces informationsns sont essentielles pour le tableau de bord « Métriques de résolution des litiges de facturation ». Comprendre les raisons les plus courantes des litiges aide à identifier les problèmes systémiques dans les processus de saisie des frais, de codage ou de facturation. La résolution de ces causes profondes peut réduire considérablement le taux de litiges et les frais administratifs nécessaires à leur résolution. Pourquoi est-ce important ? : Explique pourquoi les factures sont contestées, offrant un aperçu direct des problèmes de prélèvement.cision ou de clarté de la facturation qui doivent être résolus. Source des données : Ceci est probablement stocké dans un module de gestion de cas ou de service client au sein d'Oracle Health, lié au compte du patient. Exemples Service facturé incorrectCharge en doubleAssurance facturée incorrectementService non rendu | |||
| Numéro de Sinistre ClaimId | L'identifiant unique de la réclamation d'assurance soumise à un payeur. | ||
| Descriptionn Cet attribut est l'ID unique attribué à une réclamation générée et envoyée à un payeur pour remboursement. Un seul événement de facturation peut entraîner une ou plusieurs réclamations au cours de son cycle de vie, par exemple si une correction est nécessaire. L'utilisation de l'ID de réclamation permet de tracer une soumission spécifique à un payeur et de la relier directement à la réponse, telle qu'un paiement ou un refus. Cela offre un niveau de suivi plus granulairesre au sein du processus plus large du cycle de revenus. Pourquoi est-ce important ? : Fournit un identifiant spécifique pour suivre le parcours d'une réclamation auprès d'un payeur, ce qui est plus granulairesre que l'événement de facturation global. Source des données : Cet ID est généré par Oracle Health lors de la création d'une réclamation et est stocké dans la table principale des réclamations. Exemples CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| Système source SourceSystem | Le système à partir duquel les données d'événement ont été extraites. | ||
| Descriptionn Cet attribut identifie l'application source ou le module d'où proviennent les données. Pour ce processus, il s'agira généralement d'« Oracle Health Revenue Cycle », mais il pourrait également spécifier différents modules au sein du système si les données sont intégrées de plusieurs endroits. Ces informationsns sont précieuses pour la gouvernance des données et le dépannage. Elles aident à confirmer la traçabilité des données et sont importantes dans les environnements où plusieurs systèmes contribuent à un seul processus complet. Pourquoi est-ce important ? : Fournit le contexte sur l'origine des données, ce qui est impératif pour la validation des données, la gouvernance et la compréhension des variations de processus qui pourraient être dépendantes du système. Source des données : Ceci est souvent une valeur statique ajoutée pendant le processus d'extraction, de transformation et de chargement (ETL) des données pour étiqueter l'origine du jeu de données. Exemples OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
Activités de Gestion du cycle de revenus (RCM)
| Activité | Descriptionn | ||
|---|---|---|---|
| Compte clos | L'activité finale, indiquant que le solde du compte est nul et qu'aucune activité supplémentaire n'est attendue. Ceci est souvent déduit lorsque le solde du compte atteint zéro. | ||
| Pourquoi est-ce important ? : Marque l'achèvement réussi du cycle de revenus. Le temps nécessaire pour atteindre cet état est une mesure clé de l'efficacité globale des processus. Source des données : Ceci est généralement inféré en identifiant la première fois que le solde impayé du compte devient nul et le reste après tous les paiements et ajustements. Capture Calculé lorsque le solde du compte atteint zéro pour la première fois après que toutes les charges et tous les paiements ont été enregistrés. Type d'événement calculated | |||
| Paiement comptabilisé | Représente l'application du paiement reçu du payeur aux charges correspondantes sur le compte du patient. Il s'agit d'une transaction financière enregistrée par un utilisateur ou un processus automatisé. | ||
| Pourquoi est-ce important ? : L'efficacité de l'enregistrement des paiements affecte l'exactitude des comptes débiteurs. Les retards peuvent fausser le tableau financier et retarder la facturation secondaire. Source des données : Trouvé dans les tables de transactions de paiement. Chaque enregistrement de paiement aura un ID de transaction unique et un horodatage associé. Capture Une transaction financière est enregistrée lorsque le paiement est appliqué au compte. Type d'événement explicit | |||
| Réclamation générée | Marque le point où les charges individuelles sont compilées en une réclamation de facturation formelle, comme un UB-04 ou un CMS-1500. Il s'agit d'un événement généré par le système qui crée la facture initiale. | ||
| Pourquoi est-ce important ? : C'est un jalon majeur qui signifie la préparation à facturer un payeur. C'est le point final pour mesurer le délai interne de la saisie des frais à la facturation. Source des données : Un événement explicite enregistré dans les journaux ou les tables de génération de réclamations. Recherchez l'horodatage de création de l'enregistrement de réclamation principal associé à la rencontre. Capture Événement enregistré lors de la création de l'enregistrement de réclamation. Type d'événement explicit | |||
| Réclamation soumise au payeur | Représente la soumission électronique ou papier de la réclamation générée à la compagnie d'assurance ou au payeur. Le système doit enregistrer la date et l'heure de cette transmission. | ||
| Pourquoi est-ce important ? : Cette activité déclenche le compte à rebours du cycle de paiement. Analyser le temps entre la soumission et le paiement est indispensable pour comprendre la performance du payeur et les Jours de Vente en Cours (JVC). Source des données : Issu du module de gestion des réclamations, qui enregistre les événements de transmission. Recherchez un horodatage de soumission ou un changement de statut à « Soumis » dans l'historique des réclamations. Capture Événement enregistré lorsque la réclamation est transmise avec succès via la chambre de compensation. Type d'événement explicit | |||
| Rencontre patient créée | Marque la création d'un compte patient pour une visite ou un service spécifique. Il s'agit généralement d'un événement explicite déclenché par le système d'enregistrement ou un flux d'admission/de sortie/de transfert (ADT). | ||
| Pourquoi est-ce important ? : Il sert de point de départ pour l'ensemble du cycle de revenus pour un événement de facturation donné, permettant l'analyse de la durée totale du processus et de la précision de l'enregistrement. Source des données : Issu des journaux du module d'enregistrement des patients ou ADT. Recherchez les événements de création de rencontre ou l'horodatage le plus ancien associé à la rencontre ou au numéro financier. Capture Événement enregistré lors de l'enregistrement ou de l'admission du patient. Type d'événement explicit | |||
| Activité de recouvrement initiée | Indique que le compte du patient a été transféré vers un processus de recouvrement en raison d'un non-paiement. Cela est généralement capturé par un changement dans la classe financière ou de statut du compte. | ||
| Pourquoi est-ce important ? : C'est une étape critique pour la gestion des créances irrécouvrables. Analyser ce qui mène à ce stade et son taux de réussite est indispensable à la santé financière. Source des données : Déduit d'un changement dans le champ de statut du compte vers 'Recouvrements' ou 'Créances irrécouvrables'. Ce changement de statut devrait avoir un horodatage associé. Capture Déduit d'un changement de statut de compte vers un état de 'Recouvrements' ou similaire. Type d'événement inferred | |||
| Charges capturées | Représente la saisie des services ou articles facturables dans le compte du patient. Cela peut se produire automatiquement à partir des systèmes cliniques ou par saisie manuelle par le personnel. | ||
| Pourquoi est-ce important ? : Cette activité est indispensablele pour mesurer le « délai de facturation », le temps entre la prestation de service et l'initiation de la facturation, qui influence les flux de trésorerie et l'intégrité des revenus. Source des données : Capturé à partir des tables de transactions de charges, identifié par l'horodatage de création de chaque ligne de charge. Dans Oracle Health, cela se trouve souvent dans les tables liées aux charges. Capture Entrée de journal de transaction créée pour chaque nouvelle charge. Type d'événement explicit | |||
| Charges codées | Représente le processus où les codeurs médicaux assignent des codes standardisés, comme CPT ou ICD-10, aux charges capturées. Cela est souvent suivi par un changement de statut sur la charge ou la rencontre. | ||
| Pourquoi est-ce important ? : Les retards de codage sont un goulot d'étranglement courant. Le suivi de cette activité aide à identifier les inefficacités dans le workflow de codage et leur impact sur les délais de facturation. Source des données : Souvent déduit d'un changement de statut sur la rencontre du patient ou le lot de charges, par exemple, de 'Non codé' à 'Codé'. Un horodatage pour ce changement de statut est requis. Capture Déduit d'un changement de statut de rencontre ou de charge vers 'Codé' ou 'Prêt pour la facturation'. Type d'événement inferred | |||
| Compte ajusté | Représente un ajustement financier apporté au solde du compte, tel qu'une provision contractuelle, un amortissement ou un escompte. Chaque ajustement est une transaction financière distincte. | ||
| Pourquoi est-ce important ? : Les ajustements impactent directement les revenus. L'analyse de leur fréquence, de leur type et de leur montant aide à identifier les fuites de revenus et les inexactitudes de facturation. Source des données : Trouvé dans les tables de transactions financières. Chaque ajustement est enregistré comme une ligne distincte avec un code de transaction et un horodatage spécifiques. Capture Une transaction financière est enregistrée avec un code d'ajustement spécifique. Type d'événement explicit | |||
| Réclamation corrigée soumise | Représente la soumission d'une réclamation révisée ou corrigée au payeur, souvent après un refus ou une demande d'informations supplémentaires. Cela est identifié par une nouvelle soumission de réclamation avec un indicateur de correction. | ||
| Pourquoi est-ce important ? : Cette activité est une partie essentielle de la boucle de reprises de la gestion des refus. Une fréquence élevée indique des problèmes de prélèvement.cision initiale des réclamations. Source des données : Capturé à partir des journaux de soumission de réclamations. Recherchez une nouvelle soumission pour une rencontre existante, souvent marquée d'un code de nouvelle soumission ou d'un numéro d'itération plus élevé. Capture Événement enregistré pour une nouvelle soumission de réclamation, souvent identifiable par un code de type de fréquence de réclamation spécifique. Type d'événement explicit | |||
| Refus contesté | Une action utilisateur ou système indiquant qu'une réclamation refusée fait l'objet d'un appel. Cela est généralement capturé comme une mise à jour de statut ou une tâche spécifique créée dans une file d'attente de travail. | ||
| Pourquoi est-ce important ? : Cette activité initie une boucle de reprises. L'analyse de la fréquence et du taux de réussite des appels est indispensablele pour optimiser les efforts de recouvrement des revenus. Source des données : Cela pourrait être un événement explicite initié par l'utilisateur ou inféré d'un changement de statut sur la réclamation, tel que « Contesté » ou « En cours de révision ». Capture Un changement de statut ou un événement enregistré lorsqu'un utilisateur initie le processus d'appel pour une réclamation refusée. Type d'événement explicit | |||
| Refus reçu | Marque l'événement où le payeur a rejeté une réclamation ou des éléments de ligne spécifiques, comme indiqué dans l'avis de remise. Cet événement est souvent déduit des codes de refus présents dans les données de remise. | ||
| Pourquoi est-ce important ? : Le suivi des refus est indispensable pour identifier les causes profondes, telles que les erreurs de codage ou les problèmes d'éligibilité, et améliorer le taux de réclamations sans erreur. Source des données : Déduit des données de remise (ERA/835). Lorsqu'une réclamation ou un élément de ligne a un montant de refus non nul et un code de motif de refus correspondant, cet événement est déclenché. Capture Déduit des données de remise contenant les codes de motif de refus (CARCs/RARCs). Type d'événement inferred | |||
| Relevé patient envoyé | Marque l'événement où une facture pour la responsabilité restante du patient est générée et envoyée au patient. Il s'agit d'une action explicite enregistrée par le module de facturation des patients. | ||
| Pourquoi est-ce important ? : Cela initie la portion du cycle de revenus relative au paiement du patient. Le suivi de cela aide à analyser l'efficacité des recouvrements auprès des patients. Source des données : Issu des journaux de facturation patient ou de correspondance. Le système doit enregistrer la date à laquelle chaque relevé a été généré ou envoyé. Capture Événement enregistré lorsqu'un relevé de patient est généré et imprimé ou envoyé électroniquement. Type d'événement explicit | |||
| Remise reçue | Indique la réception d'un avis de remise électronique (ERA) ou d'une explication des avantages (EOB) papier du payeur. Ce document détaille les charges qui ont été payées, refusées ou ajustées. | ||
| Pourquoi est-ce important ? : C'est la première réponse du payeur et c'est impératif pour comprendre la vitesse de paiement et identifier rapidement les tendances de refus. Source des données : Comptabilisé dans le module de traitement des remises. Recherchez l'horodatage d'importation ou de création du fichier ERA, comme un fichier de transaction 835, lié à la réclamation. Capture Événement enregistré lors de l'importation et du traitement du fichier de remise du payeur (par exemple, ANSI 835). Type d'événement explicit | |||
Guides d'extraction
Étapes
- Demander l'accès à la base de données : Obtenez des identifiants en lecture seule pour la base de données du cycle de revenus Oracle Health. Vous aurez besoin d'un accès aux schémas contenant les données patient, de rencontre, de facturation et de transactions financières. Cela nécessite généralement l'approbation des équipes de sécurité informatique et d'administration de bases de données.
- Identifier les noms de schémas et de tables : Collaborez avec un administrateur de base de données ou un analyste système pour confirmer les noms exacts de schémas et de tables pour votre instance Oracle Health. Les noms fournis dans la requête sont des espaces réservés courants et doivent être associés à votre environnement spécifique.
- Installer un client SQL : Installez un client SQL compatible, tel qu'Oracle SQL Developer ou DBeaver, sur votre poste de travail. Cet outil sera utilisé pour se connecter à la base de données et exécuter le script d'extraction.
- Établir une connexion à la base de données : Configurez une nouvelle connexion à la base de données dans votre client SQL en utilisant l'hôte, le port, le nom de service et les identifiants fournis. Testez la connexion pour vous assurer qu'elle est réussie.
- Personnaliser la requête SQL : Copiez le script SQL fourni dans une nouvelle fenêtre d'éditeur de requête. Localisez les valeurs d'espaces réservés, telles que
[START_DATE]et[END_DATE], et remplacez-les par la plage de dates souhaitée pour votre analyse (par exemple, '2023-01-01'). Ajustez toutes les conditions de filtre en fonction de vos besoins analytiques spécifiques, tels que le filtrage pour une classe de patient particulière. - Exécuter le script d'extraction : Exécutez le script SQL personnalisé. La requête est conçue pour être complète et peut prendre de plusieurs minutes à plusieurs heures, en fonction de la plage de dates et de la taille de votre base de données.
- Examiner les résultats initiaux : Une fois la requête terminée, examinez les quelques centaines de premières lignes dans la grille de résultats de votre client SQL. Vérifiez les erreurs évidentes, telles que les colonnes entièrement nulles ou les formats de données incorrects, pour vous assurer que le script s'est exécuté correctement.
- Exporter les données au format CSV : Exportez l'ensemble du jeu de résultats vers un fichier CSV. Utilisez l'encodage UTF-8 pour éviter les problèmes de caractères. Assurez-vous que le fichier exporté comprend une ligne d'en-tête avec les noms de colonnes spécifiés dans les alias de requête (par exemple, "BillingEvent", "(ActivityName)").
- Préparer le téléversement : Avant de téléverser vers un outil de process mining, ouvrez le fichier CSV pour confirmer son intégrité. Vérifiez que le format de l'horodatage est cohérent et que les en-têtes de colonnes correspondent exactement aux attributs requis. Le fichier est maintenant prêt pour le téléversement.
Configuration
- Plage de dates : La requête utilise les espaces réservés
[START_DATE]et[END_DATE]. Il est indispensable de définir une plage de dates spécifique et raisonnable pour contrôler le volume de données. Une période de 3 à 6 mois est recommandée pour une analyse initiale. - Filtrage : L'ensemble de données initial est filtré par la date d'enregistrement des rencontres (
reg_dt_tm) dans la sectionRelevantEncounters. Vous pouvez ajouter d'autres clausesWHEREà cette section pour affiner la portée, par exemple,e.patient_class_code IN ('INPATIENT', 'OUTPATIENT')pour vous concentrer sur des types de rencontres spécifiques. - Performance : L'interrogation directe d'une base de données sur un système de production peut avoir un impact sur les performances. Il est fortement recommandé d'effectuer cette extraction pendant les heures creuses ou sur une réplique en lecture seule de la base de données de production si disponible.
- Prérequis : Cette méthode nécessite un compte utilisateur de base de données avec des privilèges
SELECTsur toutes les tables référencées dans la requête. Ces tables comprennent les tables de rencontre, de facturation, de frais, de réclamation, de remise et de transaction financière. - Mappage des tables et colonnes : Le script fourni utilise des noms courants et représentatifs pour les tables et les colonnes. Vous devez les valider et les mapper aux noms réels dans le schéma de base de données Oracle Health de votre organisation. Par exemple,
FINANCIAL_TRANSACTIONpourrait être nomméAR_TRANSACTIONSdans votre système.
a Exemple de requête sql
WITH RelevantEncounters AS (
SELECT
e.billing_event_id
FROM ENCOUNTER e
WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
e.billing_event_id AS "BillingEvent",
'Patient Encounter Created' AS "ActivityName",
e.reg_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cd.billing_event_id AS "BillingEvent",
'Charges Captured' AS "ActivityName",
cd.charge_entry_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cd.charge_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
ch.billing_event_id AS "BillingEvent",
'Charges Coded' AS "ActivityName",
ch.coded_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cl.billing_event_id AS "BillingEvent",
'Claim Generated' AS "ActivityName",
cl.create_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Claim Submitted To Payer' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
ra.billing_event_id AS "BillingEvent",
'Remittance Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Payment Posted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
rd.billing_event_id AS "BillingEvent",
'Denial Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
at.billing_event_id AS "BillingEvent",
'Denial Appealed' AS "ActivityName",
at.appeal_filed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Corrected Claim Submitted' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
psl.billing_event_id AS "BillingEvent",
'Patient Statement Sent' AS "ActivityName",
psl.statement_sent_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
psl.statement_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
ash.billing_event_id AS "BillingEvent",
'Collection Activity Started' AS "ActivityName",
ash.status_change_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ash.account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Account Adjusted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
ft.transaction_amount AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
e.billing_event_id AS "BillingEvent",
'Account Closed' AS "ActivityName",
e.account_closed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
0 AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL;