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
- Attributs recommandés à collecter
- Activités clés à suivre
- Conseils d’extraction
Attributs de gestion du cycle de revenus
| Nom | Description | ||
|---|---|---|---|
| Événement de facturation BillingEvent | Identifiant unique d’une prestation de service ou d’une livraison de produit donnant lieu à des frais. Il sert d’identifiant principal du cas. | ||
| Description L’événement de facturation est l’identifiant central qui relie toutes les activités du cycle de revenus pour un élément facturable donné. Il commence lorsqu’un service est rendu et se termine lorsque le compte est entièrement réglé ou clôturé. Dans une analyse de Process Mining, cet attribut est essentiel pour reconstituer le parcours complet de chaque frais. Il permet de suivre, pour chaque événement de facturation, des activités telles que la saisie des frais, l’envoi de la demande de remboursement, l’imputation du paiement et le traitement des rejets. Vous obtenez ainsi une vue claire du déroulement du processus et de ses variations. Pourquoi est-ce important ? Il s’agit de l’ID de cas fondamental, indispensable pour relier toutes les étapes du processus et analyser le cycle de vie complet de la génération des revenus et du recouvrement pour chaque service. Où trouver ces données Il s’agit souvent d’un identifiant unique de compte hospitalier (HAR) ou d’une session de frais spécifique dans Epic Resolute. Consultez la documentation d’Epic Resolute pour connaître les tables concernées, comme celles des dossiers HAR ou des sessions de frais. Exemples BE10098765BE20012345BE30054321 | |||
| Horodatage de l’événement EventTimestamp | Date et heure précises auxquelles une activité ou un événement s’est produit. | ||
| Description L’horodatage de l’événement indique le moment où une activité a eu lieu. Ces données temporelles sont essentielles pour comprendre le calendrier et l’ordre des événements du cycle de revenus. Les horodatages servent à calculer les délais entre les activités, par exemple le délai de saisie des frais ou le temps d’imputation des paiements. Ils permettent de repérer les goulots d’étranglement, de mesurer les temps de cycle et d’analyser les performances du processus sur différentes périodes. Des horodatages exacts sont indispensables à presque tous les KPI et Dashboards fondés sur le temps. Pourquoi est-ce important ? Cet attribut est indispensable au calcul de toutes les métriques temporelles, notamment les temps de cycle et les durées, qui permettent de repérer les retards et les inefficacités. Où trouver ces données Cet attribut figure dans les tables de transactions ou de journaux d’événements d’Epic Resolute et est associé à chaque activité enregistrée. Les noms de champs se terminent souvent par Dt, DTTM ou Time. Exemples 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Nom de l’activité ActivityName | Nom de l’événement ou de la tâche effectuée dans le processus de gestion du cycle de revenus. | ||
| Description Cet attribut décrit une étape du cycle de revenus, par exemple « Frais saisis », « Demande de remboursement envoyée à l’organisme payeur » ou « Paiement reçu ». Chaque activité correspond à une étape distincte de la facturation d’un service et du recouvrement du paiement. L’analyse des activités est au cœur du Process Mining. Elle permet de visualiser la cartographie du processus, de repérer les parcours fréquents et les goulots d’étranglement entre les étapes, et de mesurer le respect des procédures opérationnelles standard. Pourquoi est-ce important ? Définit les étapes de la cartographie du processus et permet de visualiser, d’analyser et d’optimiser le déroulement du travail dans le cycle de revenus. Où trouver ces données Cet attribut est généralement extrait des journaux d’événements, des pistes d’audit ou des enregistrements de changement de statut dans les modules de facturation et de gestion des demandes d’Epic Resolute. Exemples Frais saisisDemande de remboursement envoyée à l’organisme payeurPaiement reçuCompte clôturé | |||
| Code du motif de rejet DenialReasonCode | Code normalisé indiquant pourquoi l’organisme payeur a rejeté une demande de remboursement. | ||
| Description Lorsqu’un organisme payeur rejette une demande, il fournit un code qui en précise le motif, par exemple « Service non couvert », « Demande en double » ou « Informations complémentaires requises ». Ces codes sont souvent normalisés sous la forme de codes CARC (Claim Adjustment Reason Codes). Cet attribut est au cœur du Dashboard « Taux et motifs de rejet des demandes ». L’analyse de la fréquence des différents codes permet de repérer les causes profondes des rejets, comme des problèmes d’accréditation, des erreurs de codage ou l’absence d’autorisation préalable, et de cibler les mesures d’amélioration. Pourquoi est-ce important ? Explique directement les motifs de rejet des demandes et fournit des éléments concrets pour réduire leur fréquence, prévenir les pertes de revenus et accélérer les paiements. Où trouver ces données Ces données figurent dans les transactions de réponse aux demandes, par exemple dans un fichier ANSI 835 reçu des organismes payeurs, puis sont stockées dans le module de gestion des demandes d’Epic Resolute. Exemples CO-16 : Informations manquantes dans la demande ou le serviceOA-18 : Demande ou service en doublePR-96 : Frais non couverts | |||
| Motif de l’ajustement AdjustmentReason | Motif d’un ajustement manuel ou automatique du solde du compte d’un patient. | ||
| Description Cet attribut explique pourquoi le solde d’un compte a été modifié autrement que par un paiement ou des frais habituels. Les motifs peuvent inclure des accords tarifaires avec les organismes payeurs, l’abandon de petits soldes ou la correction d’erreurs d’imputation. Cet attribut est essentiel au Dashboard « Volume des ajustements de compte par type ». L’analyse des motifs d’ajustement permet aux organisations de repérer les pertes de revenus, de comprendre l’incidence des contrats avec les organismes payeurs et de détecter d’éventuelles inefficacités ou erreurs dans le processus de facturation. Pourquoi est-ce important ? Explique les modifications des soldes de compte et aide à repérer les pertes de revenus et les problèmes de précision de la facturation, afin de réduire les abandons de créances évitables. Où trouver ces données Figure dans le détail des transactions d’ajustement du module de comptabilité des patients d’Epic Resolute. Exemples Accord tarifaireAbandon d’un petit soldeCorrection de frais en double | |||
| Service de facturation BillingDepartment | Service ou équipe fonctionnelle responsable de l’événement de facturation ou de l’activité. | ||
| Description Cet attribut indique l’unité organisationnelle associée à l’événement de facturation ou responsable d’une activité précise, par exemple « Facturation des patients hospitalisés », « Facturation des patients externes » ou « Équipe de gestion des rejets ». Cette dimension est essentielle au Dashboard « Indicateurs de performance du service de facturation ». Elle permet de comparer côte à côte des métriques clés, comme les taux de rejet ou les délais de saisie des frais. La direction peut ainsi repérer les services les plus performants, harmoniser les bonnes pratiques et répartir les ressources efficacement. Pourquoi est-ce important ? Permet de comparer les performances des différents services, de repérer les bonnes pratiques et de déterminer où des améliorations ou des ressources supplémentaires sont nécessaires. Où trouver ces données Ces informations peuvent être associées à la fiche de l’utilisateur, au compte du patient ou au lieu de prestation dans Epic Resolute. Exemples Facturation en cardiologieRCM en radiologieService central de facturation | |||
| Solde restant dû OutstandingBalance | Montant restant dû par l’organisme payeur ou le patient pour l’événement de facturation. | ||
| Description Cet attribut représente le solde actuel des comptes clients pour un événement de facturation donné au moment de l’activité. Il reflète la situation financière du cas tout au long de son cycle de vie. Le solde restant dû est essentiel aux rapports financiers et au « Rapport d’ancienneté des soldes impayés ». Son analyse au fil du temps et selon différentes dimensions, comme l’organisme payeur ou le service, aide à prioriser le recouvrement, à gérer la trésorerie et à évaluer les risques financiers. Pourquoi est-ce important ? Mesure directement l’incidence financière des retards de processus et aide à prioriser le recouvrement, à gérer la trésorerie et à suivre les comptes clients. Où trouver ces données Il s’agit d’un champ essentiel de la fiche du compte patient ou du compte hospitalier (HAR) dans Epic Resolute. Ce solde cumulé est mis à jour au fil des transactions financières. Exemples 1500.00250.750.00 | |||
| Type de service ServiceType | Catégorie ou type de service médical fourni. | ||
| Description Cet attribut classe le service facturable, par exemple « Radiologie », « Chirurgie », « Consultation » ou « Passage aux urgences ». Il apporte un contexte clinique aux données financières. L’analyse du cycle de revenus par type de service peut révéler des variations de processus propres à certains domaines cliniques. Par exemple, les interventions chirurgicales peuvent nécessiter une saisie des frais et des autorisations plus complexes qu’une consultation classique, ce qui entraîne des pratiques et des difficultés différentes. Pourquoi est-ce important ? Apporte un contexte clinique aux données financières et permet d’analyser l’incidence des différents types de services médicaux sur le processus du cycle de revenus et son efficacité. Où trouver ces données Dérivé du référentiel des descriptions de frais (CDM), de la ligne de service ou du service associé à la transaction de frais dans Epic. Exemples Chirurgie avec hospitalisationRadiologie ambulatoireServices d’urgence | |||
| Utilisateur responsable ResponsibleUser | Identifiant de l’utilisateur ou de l’employé qui a effectué l’activité. | ||
| Description Cet attribut contient l’identifiant, le nom ou le numéro d’employé de la personne responsable d’une tâche précise du cycle de revenus. Il peut s’agir du professionnel de santé qui a saisi les frais, de l’agent de facturation qui a envoyé une demande ou du chargé de recouvrement qui a effectué le suivi d’un rejet. L’analyse par utilisateur permet de repérer les personnes les plus performantes, de cerner les besoins de formation et de comprendre la répartition de la charge de travail. Elle est utile à la gestion des performances et à l’examen des écarts de processus associés à certaines personnes ou à certains rôles. Pourquoi est-ce important ? Permet d’analyser les performances par personne ou par rôle, et de repérer les besoins de formation, les déséquilibres de charge de travail et les goulots d’étranglement liés aux ressources. Où trouver ces données Cet attribut figure généralement dans les pistes d’audit ou les journaux de transactions d’Epic Resolute. Il est souvent associé à une table de données de référence sur les utilisateurs, par exemple un enregistrement EMP. Exemples j.doebsmith123User7890 | |||
| Automatisé IsAutomated | Indicateur booléen précisant si l’activité a été exécutée par un système ou un processus automatisé. | ||
| Description Cet indicateur distingue les tâches exécutées automatiquement par le système, comme la génération automatique des demandes de remboursement ou les contrôles d’admissibilité, de celles effectuées manuellement par un utilisateur. L’analyse de cet attribut permet de comprendre le degré d’automatisation du processus. Elle peut servir à comparer l’efficacité et les taux d’erreur des activités automatisées et manuelles, à repérer de nouvelles possibilités d’automatisation et à suivre les performances des robots ou des règles système existants. Pourquoi est-ce important ? Distingue les activités exécutées par le système de celles réalisées par des personnes. Cette distinction est essentielle pour évaluer les effets de l’automatisation et repérer de nouvelles possibilités. Où trouver ces données Cet attribut est souvent déterminé en vérifiant si le « ResponsibleUser » d’une activité correspond à un compte système ou de service, ou en signalant les noms d’activité connus pour être automatisés. Exemples truefalse | |||
| Date d’échéance du paiement PaymentDueDate | Date à laquelle le paiement du service facturé doit être effectué. | ||
| Description Cet attribut indique la date limite de paiement figurant sur la facture ou définie par les contrats avec les payeurs. Il sert de référence pour mesurer le respect des délais de paiement. La date d’échéance est indispensable à la création du « Rapport d’ancienneté des soldes impayés ». En comparant la date du jour à la date d’échéance des soldes ouverts, les comptes clients peuvent être répartis par ancienneté, par exemple entre 0 et 30 jours ou entre 31 et 60 jours de retard. Cette répartition aide à prioriser le recouvrement des comptes les plus en retard. Pourquoi est-ce important ? Sert de base à l’analyse de l’ancienneté des comptes clients, essentielle pour prioriser le recouvrement et gérer le risque financier lié aux factures impayées. Où trouver ces données Cette date est souvent calculée à partir de la date de facture et des conditions de paiement enregistrées dans le contrat du payeur ou dans les informations du compte patient d’Epic. Exemples 2023-05-302023-06-152023-07-01 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation ou extraction des données de cet événement depuis le système source. | ||
| Description Cet attribut indique la fraîcheur des données, c’est-à-dire la dernière fois où l’enregistrement a été extrait d’Epic Resolute et intégré au jeu de données de Process Mining. Il permet d’évaluer l’actualité de l’analyse et de valider les données. Les utilisateurs peuvent ainsi savoir s’ils consultent les informations les plus récentes disponibles. Cet attribut est également essentiel à la gestion des cycles d’actualisation des données. Pourquoi est-ce important ? Permet aux utilisateurs de connaître l’actualité des données analysées, un élément essentiel pour prendre des décisions métier exactes et à jour. Où trouver ces données Cet horodatage est ajouté lors de l’ingestion des données par le processus ETL (extraction, transformation, chargement). Exemples 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Heure de fin de l’événement EventEndTime | Horodatage indiquant la fin d’une activité, utile pour calculer sa durée. | ||
| Description Cet attribut enregistre l’heure à laquelle une activité est terminée. De nombreuses activités sont des événements instantanés, pour lesquels StartTime est égal à EndTime. D’autres tâches ont une durée mesurable, comme un appel de suivi après un refus. Lorsque cette information est disponible, EndTime permet de calculer directement la durée de traitement de l’activité (« EndTime » - « StartTime »). Ce calcul est plus précis qu’une estimation fondée sur l’heure de début de l’activité suivante, car il tient compte du temps d’inactivité entre les étapes. Cet attribut est essentiel au calcul de l’attribut « ProcessingTime ». Pourquoi est-ce important ? Permet de calculer précisément le temps nécessaire à l’exécution de chaque activité, ce qui est essentiel pour repérer les tâches inefficaces et mesurer la productivité des ressources. Où trouver ces données Cette information peut être disponible dans certains modules d’Epic Resolute qui enregistrent le début et la fin des tâches, notamment les journaux de files de travail ou de gestion des activités. Elle n’est souvent pas suivie explicitement. Exemples 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| ID de la demande de remboursement ClaimId | Identifiant unique attribué à une demande de remboursement envoyée à un payeur. | ||
| Description Cet attribut correspond à l’ID du formulaire de demande de remboursement (par exemple, CMS-1500 ou UB-04) envoyé à un payeur. Un même événement de facturation peut donner lieu à plusieurs demandes si les services sont refacturés ou font l’objet d’un recours. Le suivi par ID de demande de remboursement est utile pour analyser en détail les sous-processus de soumission des demandes et de gestion des refus. Il permet de distinguer les activités liées à la demande initiale de celles qui concernent une demande ultérieure, soumise à nouveau pour le même service. Pourquoi est-ce important ? Fournit un identifiant détaillé pour suivre le cycle de vie de chaque demande de remboursement, ce qui est essentiel pour analyser les nouvelles soumissions et les recours. Où trouver ces données Généré par le module de gestion des demandes de remboursement d’Epic Resolute lors de la création d’une demande. Il est stocké dans les tables de données des demandes. Exemples CLM-2023-98765CLAIM-0012345623189A4567 | |||
| ID du patient PatientId | Identifiant unique du patient qui reçoit le service. | ||
| Description Cet attribut correspond au numéro de dossier médical (MRN) ou à un autre identifiant unique du patient. Il relie l’événement de facturation financière à une personne précise. Pour protéger la vie privée des patients, cet attribut n’est généralement pas utilisé comme dimension d’analyse principale. Il reste toutefois essentiel à la validation des données et peut servir à regrouper tous les événements de facturation d’un patient afin de comprendre son parcours financier dans son ensemble. Il est également important pour toute intégration éventuelle avec des données de processus cliniques. Pourquoi est-ce important ? Relie les données financières à un patient précis, ce qui permet de valider les données et, éventuellement, d’analyser l’ensemble du parcours du patient. Son utilisation exige toutefois une attention particulière en raison des enjeux de confidentialité. Où trouver ces données Identifiant fondamental présent dans l’ensemble d’Epic, associé aux dossiers d’inscription et de compte du patient. Exemples MRN-1234567MRN-8765432MRN-5551234 | |||
| Montant ajusté AdjustedAmount | Valeur monétaire d’une transaction d’ajustement. | ||
| Description Ce champ enregistre le montant exact, en dollars, d’un ajustement de compte. Il peut être positif ou négatif et correspond alors à un crédit ou à un débit du solde du compte. Ce montant est la principale métrique du Dashboard « Volume des ajustements de compte par type ». Le total par motif d’ajustement donne une vision claire de l’incidence financière des différents types d’ajustements : il permet notamment de comparer les revenus annulés en raison d’obligations contractuelles aux pertes dues à des erreurs pouvant être corrigées. Pourquoi est-ce important ? Quantifie l’incidence financière des ajustements de compte et permet ainsi de mesurer les pertes de revenus et le coût des erreurs de facturation. Où trouver ces données Se trouve dans les tables détaillées des transactions financières d’Epic Resolute et est associé aux transactions de type ajustement. Exemples -1250.45-50.0025.10 | |||
| Nom de l’organisme payeur PayerName | Nom de la compagnie d’assurance, de l’organisme public ou de toute autre partie responsable du paiement. | ||
| Description Cet attribut identifie le principal organisme payeur associé à l’événement de facturation, par exemple « Blue Cross Blue Shield », « Medicare » ou « Aetna ». En cas de paiement direct, il peut s’agir du patient. L’analyse du processus par organisme payeur peut révéler que certains d’entre eux présentent des taux de rejet plus élevés, des délais de paiement plus longs ou des exigences plus complexes. Ces informations permettent d’adapter les stratégies de facturation à chaque organisme pour gagner en efficacité et accélérer les paiements. Pourquoi est-ce important ? Permet d’analyser les performances par organisme payeur, de repérer ceux qui affichent des taux de rejet élevés ou des délais de paiement longs, et de cibler les stratégies de suivi. Où trouver ces données Ces informations font partie des détails de couverture du patient et sont associées au compte hospitalier (HAR) dans Epic Resolute. Exemples Medicare, partie BUnitedHealthcareAetna PPO | |||
| Système source SourceSystem | Système d’information à l’origine des données. | ||
| Description Cet attribut identifie le système source de l’enregistrement, qui est ici Epic Resolute. Dans un environnement où plusieurs systèmes sont intégrés, il permet de distinguer l’origine des données. Même s’il peut sembler redondant lorsque les données proviennent d’un seul système, il s’agit d’une bonne pratique en matière de gouvernance des données et d’évolutivité. Il permet de conserver une origine claire si des données issues d’autres systèmes, par exemple d’une plateforme distincte de recouvrement, sont intégrées par la suite. Pourquoi est-ce important ? Cet attribut précise la provenance des données et leur contexte. Il permet d’en connaître clairement l’origine, ce qui est essentiel à la gouvernance des données et au diagnostic des problèmes. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données pour indiquer l’origine du jeu de données. Exemples Epic ResoluteEpicResolute_V2023 | |||
| Temps de cycle total du cycle de revenus TotalRevenueCycleTime | Durée totale calculée entre le premier événement de service et le paiement final ou la clôture du compte. | ||
| Description Cet indicateur clé de performance (KPI) au niveau du cas mesure la durée de bout en bout du cycle de revenus pour un événement de facturation donné. Il est généralement calculé comme l’écart entre l’activité « Service fourni » et l’activité finale « Paiement reçu » ou « Compte clôturé ». Cette métrique donne une vue d’ensemble de l’efficacité du processus de gestion du cycle de revenus (RCM). Son suivi dans le temps permet de mesurer les effets des initiatives d’amélioration des processus et constitue un indicateur clé de la vitesse de conversion des créances en trésorerie. Pourquoi est-ce important ? Donne une vue d’ensemble de l’efficacité du processus, de bout en bout, et mesure directement le temps nécessaire pour convertir un service en trésorerie. Où trouver ces données Cette métrique est calculée dans l’outil de Process Mining en filtrant les premier et dernier événements de chaque cas, puis en calculant l’écart entre leurs horodatages. Exemples 259200038880005184000 | |||
Activités de gestion du cycle de revenus
| Activité | Description | ||
|---|---|---|---|
| Compte clôturé | Cette dernière activité indique que le solde restant dû pour l’événement de facturation est nul et qu’aucune autre activité n’est en attente. La clôture peut résulter d’un paiement intégral, d’ajustements ou d’un abandon de créance. | ||
| Pourquoi est-ce important ? Cet événement marque la fin du cycle de revenus pour un événement de facturation. La durée totale entre la prestation du service et la clôture constitue un KPI important de l’efficacité globale du processus. Où trouver ces données Cet événement est généralement déduit. Il correspond au moment où le solde du compte associé à l’événement de facturation devient nul et le reste. Données à recueillir Déduit en calculant le solde cumulé du compte et en repérant l’horodatage de la dernière transaction qui l’a ramené à zéro. Type d’événement inferred | |||
| Demande de remboursement envoyée à l’organisme payeur | Cet événement correspond à l’envoi officiel de la demande de remboursement à l’organisme payeur pour examen. Dans Epic, il est suivi et consigné lorsque le fichier électronique est transmis à la chambre de compensation ou à l’organisme payeur. | ||
| Pourquoi est-ce important ? Cette étape marque le début du délai de paiement de l’organisme payeur. Son analyse permet de mesurer l’efficacité de la transmission des demandes et de suivre le KPI du délai d’envoi de la facture à l’organisme payeur. Où trouver ces données Cet événement est enregistré explicitement dans Resolute. Le dossier de la demande comporte un statut d’envoi et un horodatage indiquant quand elle a été transmise. Données à recueillir Récupérez l’horodatage correspondant au passage du statut de la demande à « Envoyée » ou « Transmise ». Type d’événement explicit | |||
| Demande de remboursement rejetée par l’organisme payeur | Cet événement correspond à la réception d’une notification de rejet de la part de l’organisme payeur. Il est enregistré lorsqu’Epic traite un avis électronique de remboursement (fichier 835) ou lorsqu’un utilisateur saisit manuellement le rejet. | ||
| Pourquoi est-ce important ? Cette activité déclenche une boucle de reprises importante. L’analyse des motifs et du nombre de rejets est essentielle pour en repérer les causes profondes, améliorer le taux de paiement dès la première soumission et réduire les délais de recouvrement. Où trouver ces données Cet événement est enregistré explicitement sous forme de transaction ou de mise à jour du statut de la demande. Les informations sur le rejet, notamment les codes de motif, sont généralement reçues par voie électronique et portées au compte. Données à recueillir Filtrez les types de transactions ou les mises à jour du statut de la demande qui signalent un rejet. Type d’événement explicit | |||
| Frais saisis | Cette activité correspond à l’enregistrement officiel des frais facturables pour les services rendus. Dans Epic, il s’agit généralement d’une transaction explicite portée au compte du patient, créée automatiquement à partir d’actes cliniques ou saisie manuellement. | ||
| Pourquoi est-ce important ? Il s’agit d’une première étape importante. Mesurer la rapidité et la précision de la saisie des frais aide à accélérer la facturation et à s’assurer que tous les services fournis sont facturés. Où trouver ces données Cet événement est enregistré explicitement dans les journaux de transactions d’Epic Resolute. Chaque frais constitue une entrée distincte avec une date de comptabilisation, une date de service et un montant. Ces informations figurent souvent dans des tables telles que ARPB_TRANSACTIONS. Données à recueillir Récupérez les transactions de comptabilisation des frais dans le journal des transactions financières du système. Type d’événement explicit | |||
| Paiement imputé au compte | Cet événement correspond à l’imputation ou à l’affectation d’un paiement reçu à des frais précis du compte du patient. Cette opération réduit le solde restant dû pour l’événement de facturation. | ||
| Pourquoi est-ce important ? Une imputation efficace des paiements est essentielle pour maintenir des soldes de compte exacts et clôturer les événements de facturation. Elle permet de déterminer correctement les soldes restants à facturer à un organisme secondaire ou à recouvrer. Où trouver ces données Il s’agit d’une transaction explicite dans Resolute. L’imputation associe une transaction de paiement à une ou plusieurs transactions de frais, association consignée dans les tables détaillées des transactions. Données à recueillir Récupérez l’enregistrement de transaction qui impute un paiement à des frais, identifiable grâce à certains types de transaction. Type d’événement explicit | |||
| Paiement reçu | Cet événement correspond à la réception d’un paiement de l’organisme payeur ou du patient. Il est généralement enregistré lors du chargement d’un avis électronique de remboursement (ERA) ou de la saisie d’un chèque dans le système. | ||
| Pourquoi est-ce important ? Cette activité marque une étape importante : le paiement est en cours de réception. Le délai entre l’envoi de la demande et la réception du paiement est un indicateur clé de la performance des comptes clients. Où trouver ces données Cet événement est enregistré explicitement comme une transaction de paiement dans Resolute. Les transactions comportent une date, une source et un montant, souvent avant leur imputation complète aux différents frais. Données à recueillir Récupérez les transactions de paiement dans le journal des transactions financières, où elles sont souvent repérables grâce à leur type. Type d’événement explicit | |||
| Service rendu | Cette activité correspond au moment où un service clinique est fourni au patient et déclenche l’événement de facturation. Elle est souvent enregistrée dans le DME Epic (EpicCare), lorsqu’un professionnel de santé valide une consultation ou un acte. | ||
| Pourquoi est-ce important ? Il s’agit de l’événement de début principal du cycle de revenus. Il est essentiel d’analyser le délai entre ce moment et la saisie des frais pour repérer les retards au démarrage de la facturation et les pertes potentielles de revenus. Où trouver ces données Cet événement est généralement déduit des horodatages des services ou des consultations dans les modules cliniques associés au compte de facturation. La date du service indiquée sur la transaction de frais constitue la donnée de référence. Données à recueillir Déduit de la date du service associée à la première transaction de frais de l’événement de facturation. Type d’événement inferred | |||
| Ajustement du compte effectué | Cette activité correspond à une transaction autre qu’un paiement qui modifie le solde du compte, par exemple un ajustement contractuel, l’abandon d’un petit solde ou une remise commerciale. Elle est enregistrée sous un type de transaction spécifique. | ||
| Pourquoi est-ce important ? L’analyse des ajustements aide à repérer les pertes de revenus. Un volume élevé de certains types d’ajustement peut révéler des problèmes de barèmes tarifaires, de contrats ou de règles internes. Où trouver ces données Les ajustements sont enregistrés explicitement dans les journaux financiers de Resolute. Chaque ajustement est associé à un type ou à un code de motif spécifique. Données à recueillir Filtrez les types de transaction correspondant aux ajustements financiers ou aux abandons de créances. Type d’événement explicit | |||
| Début du suivi d’un rejet | Cette activité marque le début du traitement interne visant à examiner et à résoudre une demande de remboursement rejetée. Elle est souvent enregistrée lorsqu’un utilisateur prend en charge la demande dans une file de travail ou en modifie le statut. | ||
| Pourquoi est-ce important ? Son suivi permet de mesurer la réactivité de l’équipe chargée des rejets. Tout délai entre le rejet et le début du suivi peut prolonger inutilement le cycle de revenus. Où trouver ces données Cet événement est généralement déduit des changements de statut de la demande ou de son historique d’affectation dans les files de travail d’Epic. Par exemple, son statut peut passer de « Rejetée » à « En cours d’examen ». Données à recueillir Déduisez cet événement d’un changement de statut de la demande ou d’une entrée du journal d’audit indiquant qu’un utilisateur a commencé à traiter le rejet. Type d’événement inferred | |||
| Demande de remboursement créée | Cette activité indique que le système a créé une demande de remboursement ou une facture à partir des frais saisis. Elle précède l’envoi de la demande à l’organisme payeur ou au patient. | ||
| Pourquoi est-ce important ? Le suivi de la création des demandes de remboursement permet de repérer les retards entre la saisie des frais et la préparation de leur envoi. Cette étape interne peut avoir une incidence sur les délais globaux de facturation. Où trouver ces données Cet événement est généralement consigné lors de l’exécution d’un traitement par lots de facturation ou de génération des demandes de remboursement. Le système enregistre un horodatage lors de la création du fichier de demande, par exemple un fichier 837, pour un compte donné. Données à recueillir Repérez les entrées de journal ou les changements de statut indiquant que la demande de remboursement a été préparée et peut être envoyée. Type d’événement explicit | |||
| Demande de remboursement soumise à nouveau | Cet événement survient après la correction d’une demande rejetée, lorsqu’elle est renvoyée à l’organisme payeur. Il s’agit d’un nouvel envoi distinct, lié à la demande d’origine. | ||
| Pourquoi est-ce important ? Cette étape fait partie de la boucle de reprises. Mesurer le délai avant le nouvel envoi et le taux de réussite des demandes soumises à nouveau est essentiel pour évaluer l’efficacité du traitement des rejets. Où trouver ces données Cet événement est enregistré explicitement, comme l’envoi initial, mais porte souvent la mention « Soumise à nouveau ». Le dossier de la demande indique un nouvel horodatage d’envoi et peut comporter un code de nouvelle soumission. Données à recueillir Récupérez l’horodatage d’une demande envoyée avec la mention « Corrigée » ou « Soumise à nouveau ». Type d’événement explicit | |||
| Solde transmis au recouvrement | Cet événement marque le transfert d’un solde impayé vers un processus de recouvrement interne ou externe. Il correspond souvent à un changement explicite du statut du compte ou de l’événement de facturation. | ||
| Pourquoi est-ce important ? Cette activité marque le début de la dernière étape de recouvrement des soldes impayés. Suivre le taux de réussite et le temps de cycle du recouvrement est essentiel pour limiter les créances irrécouvrables. Où trouver ces données Il s’agit généralement d’un événement explicite. Epic permet de transférer des comptes à des agences de recouvrement, ce qui crée une entrée de journal ou modifie le statut du compte. Données à recueillir Repérez le changement de statut ou la transaction indiquant que le compte a été confié à une agence de recouvrement. Type d’événement explicit | |||
Guides d’extraction
Étapes
- Établissez la connexion à la base de données : obtenez des identifiants en lecture seule pour la base de données Epic Clarity. Utilisez un client SQL standard, comme DBeaver ou Microsoft SQL Server Management Studio, pour vous connecter au serveur de base de données.
- Repérez les tables principales : les principales tables à utiliser pour cette extraction sont
HSP_ACCOUNTpour les informations sur les cas,HSP_TRANSACTIONSpour les événements financiers,CLP_CLAIM_INFOpour le statut des demandes de remboursement etF_ARHB_TX_SET_POST_HXpour les détails de comptabilisation des paiements. Vous devrez également joindre des fichiers de référence, commeCLARITY_EMP, pour obtenir les informations sur les utilisateurs. - Définissez le périmètre : avant de rédiger la requête, déterminez le périmètre de votre analyse. Définissez une période précise, généralement de 3 à 6 mois, et indiquez les secteurs de service hospitalier (
SERV_AREA_ID) ou les classes de compte à inclure ou à exclure. - Rédigez la requête SQL : construisez une requête SQL avec une expression de table commune (CTE) afin de sélectionner d’abord les valeurs
HSP_ACCOUNT_IDcorrespondant au périmètre défini. Elles constitueront la population de base des événements de facturation. - Réunissez les requêtes pour chaque activité : pour chacune des 12 activités requises, rédigez une instruction
SELECTdistincte qui extrait les données des tables concernées. Reliez chaque requête à la CTE initiale pour ne conserver que les comptes visés par l’analyse. - Combinez les requêtes avec UNION ALL : utilisez l’opérateur
UNION ALLpour réunir les résultats de toutes les requêtes d’activité dans un seul journal d’événements cohérent. Les lignes de chaque requête sont ainsi ajoutées les unes à la suite des autres. - Associez les champs au schéma standard : dans chaque instruction
SELECT, donnez aux colonnes des alias correspondant au schéma ProcessMind requis :BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, etc. UtilisezNULLpour les attributs qui ne s’appliquent pas à une activité donnée. - Exécutez et affinez la requête : lancez la requête complète sur la base de données Clarity. Le volume des tables peut entraîner un temps d’exécution important. Si les performances sont insuffisantes, réduisez la période ou ajoutez des filtres plus précis dans la CTE initiale.
- Vérifiez les résultats : une fois la requête terminée, examinez les premières centaines de lignes. Vérifiez que toutes les colonnes sont présentes, que les horodatages suivent un format cohérent et que les différentes valeurs
ActivityNameapparaissent comme prévu. - Exportez les résultats au format CSV : exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Vérifiez que le fichier utilise l’encodage UTF-8 et comporte une ligne d’en-tête avec les noms de colonnes corrects.
- Préparez l’importation : avant d’importer le fichier dans ProcessMind, ouvrez le CSV pour vérifier qu’il ne comporte aucune erreur de format. Vérifiez que les horodatages suivent un format cohérent, par exemple
YYYY-MM-DD HH:MI:SS. Le fichier est alors prêt à être importé.
Configuration
- Connexion à la base de données : un compte utilisateur en lecture seule ayant accès à la base de données Epic Clarity est nécessaire.
- Paramètres de période : la requête fournie utilise les variables
@StartDateet@EndDate. Vous devez les définir pour préciser la période d’analyse. Une période de 3 à 6 mois est recommandée afin de trouver un équilibre entre le volume de données et les performances. - Association des tables et des colonnes : la requête suppose que les tables et les colonnes portent les noms standard de Clarity. La configuration ou la version d’Epic utilisée par votre organisation peut présenter des différences. Vous devrez peut-être adapter les noms des tables et des colonnes, ainsi que les conditions de jointure.
- Codes de transaction et de statut : la requête contient des espaces réservés comme
[Your Denial Tx Type]et[Your Collections Status Code]. Consultez les administrateurs de votre système Epic ou les fichiers de référence concernés, commeZC_TX_TYPEouZC_ACCOUNT_STATUS, pour trouver les codes correspondant à votre instance. - Filtrage : pour améliorer les performances et cibler l’analyse, ajoutez des filtres à la CTE initiale
BaseAccounts. Vous pouvez notamment utiliserSERV_AREA_IDpour limiter l’analyse à un secteur de service hospitalier ouACCOUNT_CLASS_Cpour vous concentrer sur la facturation des patients hospitalisés ou ambulatoires.
Exemple de requête sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp; Étapes
- Vérifiez que vous disposez d’un accès autorisé aux données du cycle de revenus d’Epic Clarity, notamment aux tables et vues sources nécessaires pour consulter l’historique des comptes, des frais, des demandes de remboursement, des refus, des paiements, des ajustements, du recouvrement et des clôtures. Les tables disponibles et les noms de colonnes varient selon les organisations Epic. Associez donc chaque espace réservé de la requête à l’objet Clarity correspondant dans votre environnement.
- Définissez la période d’extraction à l’aide de [Start date parameter] et [End date parameter]. Commencez par une période de trois à six mois et ne l’allongez qu’après avoir vérifié les performances de la requête et l’exhaustivité des événements.
- Définissez l’association de BillingEvent. Par défaut, la requête utilise HSP_ACCOUNT.HSP_ACCOUNT_ID comme identifiant de cas, lorsqu’il est disponible. Si votre organisation définit un événement de facturation au niveau d’un frais, d’une demande de remboursement ou d’une rencontre, remplacez cette association par l’identifiant approuvé et utilisez-le de manière cohérente pour toutes les sources d’activité.
- Associez chaque activité source à un horodatage et à un attribut source faisant autorité. Pour Service Rendered, utilisez l’horodatage documenté de fin du service ou de la rencontre. Pour Charges Captured, utilisez l’horodatage de comptabilisation des frais. Pour Claim Generated et Claim Submitted to Payer, utilisez les horodatages correspondants du cycle de vie de la demande. Pour les refus, le suivi, les nouvelles soumissions, les paiements, les ajustements, le recouvrement et la clôture, utilisez les horodatages documentés des transactions ou des statuts.
- Remplacez tous les espaces réservés entre crochets dans la requête, notamment [Your service source table], [Your charge source table], [Your claim source table], [Your denial source table], [Your follow-up source table], [Your payment source table], [Your adjustment source table], [Your collections source table] et [Your account closure source table]. Ne remplacez pas ces valeurs par des codes de transaction non documentés. Utilisez les valeurs de transaction ou de statut approuvées par votre équipe de reporting Epic.
- Exécutez la requête dans le client SQL ou la plateforme de reporting approuvés par votre organisation. Vérifiez que les douze libellés d’activité apparaissent sous forme de lignes explicites. ProcessMind ne déduit pas les événements manquants du cycle de vie à partir des soldes, des statuts ou de l’ordre des événements.
- Vérifiez le schéma des résultats. Le résultat doit contenir BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance et ServiceType. Conservez les informations de fuseau horaire ou d’heure locale avec les horodatages et gardez les identifiants sources dans un extrait d’audit interne, si cela est autorisé.
- Vérifiez l’ordre chronologique des événements pour chaque BillingEvent, le traitement des doublons, les taux de valeurs nulles, le nombre d’activités et le rapprochement avec les rapports du système source. Examinez les événements hors de la période demandée lorsqu’ils sont nécessaires pour interpréter les cas commencés avant ou terminés après cette période.
- Exportez les résultats dans un fichier délimité ou via une connexion à une base de données prise en charge par ProcessMind. Utilisez une ligne par événement, des noms de colonnes stables, un format d’horodatage cohérent, l’encodage UTF-8 et aucune cellule fusionnée ni aucun total de présentation. Lors de l’importation, définissez BillingEvent comme identifiant de cas, ActivityName comme activité et EventTimestamp comme horodatage de l’événement.
Configuration
- Association des sources : les implémentations d’Epic Clarity varient. Remplacez chaque nom de table, de vue ou de colonne entre crochets par un objet documenté ou une couche de reporting approuvée dans votre environnement. Ne partez pas du principe qu’une table ou un champ existe simplement parce qu’il est courant dans une autre implémentation d’Epic.
- Identifiant de cas : la requête utilise par défaut HSP_ACCOUNT.HSP_ACCOUNT_ID. Vérifiez si votre organisation définit BillingEvent comme un compte, une rencontre, une réclamation, une charge ou une autre clé métier approuvée.
- Période : commencez par trois à six mois. Prévoyez une période antérieure si des cas peuvent débuter avant la fenêtre de reporting, ainsi qu’une période de suivi si les réclamations, refus, paiements ou clôtures peuvent survenir après la date de service.
- Horodatages des activités : configurez un horodatage de référence pour chaque activité. N’utilisez pas l’heure d’extraction, de chargement du fichier ou de mise à jour du statut à la place de l’heure réelle de l’événement métier, sauf si celle-ci est documentée comme l’horodatage de l’événement dans le système source.
- Filtres : appliquez les filtres [Company Code filter], [Document Type filter], [Department filter], payeur, secteur de service et catégorie de compte uniquement si leur définition est documentée et qu’ils sont nécessaires à l’analyse. Utilisez les mêmes filtres dans toutes les branches UNION ALL.
- Association des transactions et des statuts : configurez les valeurs approuvées par votre organisation pour la comptabilisation des frais, la création et la soumission des réclamations, les refus, les relances, les nouvelles soumissions, la réception et la comptabilisation des paiements, les ajustements, le recouvrement et la clôture. La requête utilise volontairement des espaces réservés, car les valeurs de transaction et les structures sources d’Epic varient selon les implémentations.
- Valeurs nulles : conservez NULL pour les attributs qui ne s’appliquent pas à une activité. Ne remplacez pas les motifs de refus ou d’ajustement, les utilisateurs, les services ou les types de service manquants par des valeurs inventées.
- Performances : limitez les lignes sources à l’aide des colonnes de date indexées et des filtres organisationnels approuvés avant de les joindre à HSP_ACCOUNT. Évitez d’appliquer des fonctions aux colonnes d’horodatage indexées dans les prédicats. Si l’historique brut est volumineux, envisagez de matérialiser chaque activité source dans une vue de reporting approuvée.
- Déduplication : ne supprimez pas les événements en double sans règle documentée. Plusieurs paiements, ajustements, soumissions ou changements de statut peuvent être valides pour un même BillingEvent.
- Prérequis : l’accès requis peut inclure une autorisation de reporting Epic Clarity, l’accès aux données du cycle de revenus et à l’historique des comptes, un environnement d’exécution SQL approuvé et l’autorisation de votre organisation pour les informations de santé protégées. La disponibilité de l’historique des réclamations, des avis de paiement, des files de travail, du recouvrement et des clôtures dépend des modules et interfaces Epic sous licence et déployés.
Exemple de requête sql
WITH
service_rendered AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Service Rendered' AS ActivityName,
CAST(s.[Service rendered timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(s.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(s.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(s.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(s.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your service source table] s
ON s.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE s.[Service rendered timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND s.[Service rendered timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND [Your company code filter]
),
charges_captured AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Charges Captured' AS ActivityName,
CAST(t.[Charge captured timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(t.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(t.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(t.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(t.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN AR_PB_TRANSACTIONS t
ON t.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE t.[Charge captured timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND t.[Charge captured timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND t.[Charge transaction filter]
AND [Your company code filter]
),
claim_generated AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Generated' AS ActivityName,
CAST(c.[Claim generated timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim generated timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim generated timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim generated status filter]
AND [Your company code filter]
),
claim_submitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
CAST(c.[Claim submitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim submitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim submitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim submitted status filter]
AND [Your company code filter]
),
claim_denied AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
CAST(d.[Denial timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(d.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(d.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(d.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(d.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(d.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your denial source table] d
ON d.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE d.[Denial timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND d.[Denial timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND d.[Denial status filter]
AND [Your company code filter]
),
denial_follow_up AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
CAST(f.[Follow-up timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(f.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(f.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(f.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(f.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(f.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your follow-up source table] f
ON f.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE f.[Follow-up timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND f.[Follow-up timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND f.[Follow-up status filter]
AND [Your company code filter]
),
claim_resubmitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
CAST(c.[Claim resubmitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim resubmitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted status filter]
AND [Your company code filter]
),
payment_received AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Received' AS ActivityName,
CAST(p.[Payment received timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment received timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment received timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment received status filter]
AND [Your company code filter]
),
payment_posted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
CAST(p.[Payment posted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment posted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment posted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment posted status filter]
AND [Your company code filter]
),
account_adjustment AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
CAST(x.[Adjustment timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(x.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(x.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(x.[Adjustment reason column] AS VARCHAR(100)) AS AdjustmentReason,
CAST(x.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(x.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your adjustment source table] x
ON x.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE x.[Adjustment timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND x.[Adjustment timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND x.[Adjustment transaction filter]
AND [Your company code filter]
),
balance_collections AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
CAST(k.[Collections timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(k.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(k.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(k.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(k.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your collections source table] k
ON k.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE k.[Collections timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND k.[Collections timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND k.[Collections status filter]
AND [Your company code filter]
),
account_closed AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Closed' AS ActivityName,
CAST(z.[Account closed timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(z.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(z.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(z.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(z.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your account closure source table] z
ON z.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE z.[Account closed timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND z.[Account closed timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND z.[Account closed status filter]
AND [Your company code filter]
)
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM service_rendered
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM charges_captured
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_generated
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_submitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_denied
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM denial_follow_up
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_resubmitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_received
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_posted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_adjustment
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM balance_collections
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_closed
ORDER BY BillingEvent, EventTimestamp, ActivityName; Prêt à commencer ?
Des données précises vous permettent d’améliorer votre processus de gestion du cycle de revenus. Commencez dès aujourd’hui à gagner en efficacité et à améliorer vos résultats financiers.
Améliorez l’efficacité : optimisez dès maintenant la gestion du cycle de revenus
Repérez les inefficacités du RCM dans Epic Resolute et réduisez le temps de cycle de 30 %.
Aucune carte bancaire requise. Commencez à optimiser dès aujourd’hui.