> Amélioration Continue des Processusus > Parcours de soins > athenahealth > Template de données

Votre modèle de données du Parcours Patient

athenahealth

Attributs du parcours patient (19) Activités du parcours patient (15) Guides d'extraction (2)

Votre modèle de données du Parcours Patient

Ce modèle fournit un guide détaillé pour la collecte des données nécessaires à l'analyse de votre parcours patient. Il décrit les attributs et activités essentiels que vous devez suivre, ainsi que des conseils clairs sur la manière d'extraire ces informations d'athenahealth. Utilisez cette ressource pour vous assurer que vos données sont prêtes pour un Process Mining efficace.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction athenahealth

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs du parcours patient

Ce sont les champs de données recommandés à inclure dans votre `journal d'événements`, essentiels pour une analyse complète et une compréhension de vos parcours patients.

5 Obligatoire 9 Recommandé 5 Facultatif

	Nom	Descriptionn
	Dernière mise à jour des données LastDataUpdate	Heure de la dernière extraction ou actualisation des données.
Descriptionn Indique la la réactualisation des données utilisées dans l'analyse. Cela aide les utilisateurs à comprendre s'ils consultent des données en temps réel ou un instantané historique. Utilisé pour gérer les `flux de données` et garantir que les `dashboards` reflètent l'état le plus actuel du processus. Pourquoi est-ce important ? : Primordial pour la gouvernance des données et la confiance des utilisateurs dans la fraîcheur du tableau de bord. Source des données : Heure système au moment de l'exécution de l'ETL. Exemples 2023-11-01T12:00:00Z2023-11-02T06:00:00Z
	Épisode patient PatientEpisodeId	Identifiant unique pour l'épisode ou le parcours patient spécifique.
Descriptionn Cet attribut sert d'Identifiant de Cas central, regroupant toutes les activités liées à une période de soins ou une condition spécifique pour un patient. Il connecte des événements disparates tels que les rendez-vous, les commandes diagnostiques et les procédures de sortie en un seul parcours cohérent. En analyse, cet ID est la clé primaire pour le Process Mining, permettant la reconstruction du flux complet. Il garantit que plusieurs visites du même patient pour différentes conditions sont traitées comme des instances de processus distinctes. Pourquoi est-ce important ? : Primordial pour définir la portée d'une seule instance de processus dans l'analyse. Source des données : Dérivé du regroupement des ID d'épisode de soins ou lié à un ID d'épisode de soins spécifique dans athenahealth. Exemples EP-2023-88491EP-2023-99102ENC-55412-GRP
	Horodatage de l'événement EventTimestamp	La date et l'heure spécifiques auxquelles l'activité s'est produite.
Descriptionn Enregistre le moment exact où une activité a eu lieu. Ceci est utilisé pour séquencer les événements chronologiquement et calculer les durées entre les étapes. Indispensable pour l'analyse basée sur le temps, y compris les temps de cycle, les temps d'attente et l'analyse du `débit`. Une haute précision est préférée pour résoudre l'ordre des événements se produisant le même jour. Pourquoi est-ce important ? : Requis pour ordonner les événements et calculer tous les KPI basés sur le temps. Source des données : Champs `horodatage` associés aux changements de statut ou aux dates de création dans les tables athenahealth. Exemples 2023-10-12T08:30:00Z2023-10-12T09:15:22Z2023-10-15T14:20:00Z
	Nom de l'activité ActivityName	Le nom de l'événement ou de la tâche effectuée dans le parcours patient.
Descriptionn Indique l'étape spécifique du processus, telle que 'Patient enregistré', 'Test diagnostique commandé' ou 'Médicament administré'. Cette chaîne de caractères définit les nœuds de la carte de processus. Utilisé pour visualiser le `flux de processus` et identifier la séquence des opérations. La standardisation de ces noms est indispensablele pour une carte de processus claire et lisible. Pourquoi est-ce important ? : Définit les étapes de la cartographie des processus et est obligatoire pour toute activité de Process Mining. Source des données : Dérivé des journaux d'audit, des changements de statut des rendez-vous ou des descriptions des lignes de réclamation. Exemples Rendez-vous programméPatient enregistréTest diagnostique commandéPatient sorti
	Système source SourceSystem	Le nom du système d'où proviennent les données.
Descriptionn Identifie le système IT responsable de la génération de l'enregistrement, en l'occurrence, 'athenahealth'. Ceci est particulièrement utile dans les environnements multi-systèmes où les données peuvent être fusionnées. Permet aux analystes de filtrer la vue par source de données et de résoudre les problèmes de qualité des données spécifiques à un système. Pourquoi est-ce important ? : Fournit la `lignage des données` et le contexte dans les configurations de Process Mining multi-systèmes. Source des données : Littéral codé en dur ou ID de configuration du système. Exemples athenahealthAthenaOneAthenaPractice
	Code de diagnostic principal PrimaryDiagnosisCode	Le code CIM-10 principal associé à l'épisode.
Descriptionn Classe la raison clinique du parcours patient. Cela fournit le contexte nécessaire pour la 'Comparaison des parcours par groupe d'âge et diagnostic'. Les analystes l'utilisent pour segmenter les parcours par condition (par exemple, Pneumonie vs. Fracture) car les différentes conditions ont des parcours et des temps de cycle très différents. Pourquoi est-ce important ? : Permet la comparaison de cas 'similaires'; les temps de cycle varient énormément selon le diagnostic. Source des données : Champs de diagnostic de l'épisode de soins ou de la réclamation (CIM-10). Exemples J18.9I10E11.9
	Groupe d'âge du patient PatientAgeGroup	Regroupement catégoriel de l'âge du patient (par exemple, 18-25, 65+).
Descriptionn Segmente les patients en cohortes démographiques. Ceci est directement requis pour le `tableau de bord` 'Comparaison des parcours par groupe d'âge et diagnostic'. Cela aide à identifier si les inefficacités de processus ou les résultats affectent de manière disproportionnée des données démographiques spécifiques, telles que les patients âgés ou pédiatriques. Pourquoi est-ce important ? : Segment démographique standard pour l'analyse des processus de soins de santé. Source des données : Dérivé de la date de naissance du patient (DOB) et de l'heure de début (StartTime). Exemples 18-2930-4965+
	Heure de fin de l'événement EventEndTime	L'heure à laquelle l'activité spécifique a été terminée.
Descriptionn Capture le temps d'achèvement d'une activité, permettant le calcul de la durée active (temps de traitement) de l'étape elle-même, distincte du temps d'attente qui la précède. Utilisé pour analyser l'efficacité des ressources et identifier les tâches qui prennent plus de temps que prévu à exécuter manuellement. Pourquoi est-ce important ? : Permet le calcul du temps de traitement actif par rapport au temps d'attente passif. Source des données : Heure de sortie, heure de vérification du résultat, ou horodatages d'achèvement spécifiques dans athenahealth. Exemples 2023-10-12T09:00:00Z2023-10-12T10:45:00Z
	ID du patient PatientId	Un identifiant unique pour le patient (anonymisé/haché).
Descriptionn Identifie de manière unique le client (patient) effectuant le parcours. Bien que similaire à l'identifiant de cas, un patient peut avoir plusieurs épisodes au fil du temps. Utilisé pour lier les visites répétées et analyser les taux de réadmission. Il est indispensable pour le KPI 'Pourcentage de réadmissions non planifiées'. Pourquoi est-ce important ? : Nécessaire pour suivre les réadmissions et l'historique du patient à travers les épisodes. Source des données : Champ 'patientid' d'athenahealth. Exemples PAT-100234PAT-559201PAT-992210
	Modalité de sortie DischargeDisposition	La destination ou le statut du patient à sa sortie.
Descriptionn Indique où le patient s'est rendu après l'épisode, par exemple 'À domicile', 'Établissement de soins de suite et de réadaptation (SSR)' ou 'Hospice'. Ceci est indispensable à la 'Planification des sorties et les Tendances de Réadmission'. Cela fournit un contexte sur la complexité de la planification des sorties requise et aide à évaluer l'efficacité des transitions de soins. Pourquoi est-ce important ? : Contexte critique pour la planification des sorties et le risque de réadmission. Source des données : Champs d'épisode de soins athenahealth ou dossiers de sortie d'hôpital. Exemples AccueilÉtablissement de soins de suite et de réadaptation (SSR)Transféré à l'hôpital de court séjourExpiré
	Nom du prestataire ProviderName	Le nom du professionnel de la santé effectuant l'activité.
Descriptionn Identifie le médecin, l'infirmière ou le technicien spécifique responsable de l'événement. Cet attribut est indispensable à l'analyse de l'utilisation des ressources. Il permet de comparer les métriques de performance, telles que le débit et le temps de cycle, entre les différents membres du personnel afin d'identifier les besoins en formation ou les déséquilibres de charge de travail. Pourquoi est-ce important ? : Clé pour le 'Taux d'utilisation des ressources' et l'analyse des passations. Source des données : Champ 'providerid' d'athenahealth résolu en nom de prestataire. Exemples Dr. SmithInfirmière JonesTech Adams
	Nom du service DepartmentName	Le département hospitalier ou clinique où l'activité a eu lieu.
Descriptionn Segmente les données de processus par unité fonctionnelle, telles que les Urgences, la Cardiologie ou la Radiologie. Ceci est indispensable pour le `tableau de bord` 'Débit départemental et passations'. L'analyse utilisant cet attribut met en évidence les points de blocage dans des zones spécifiques et aide à optimiser le flux de patients inter-départemental. Pourquoi est-ce important ? : Primordial pour identifier les points de blocage organisationnels et les inefficacités de transfert. Source des données : Champ 'departmentid' d'athenahealth résolu en nom de département. Exemples Service des urgencesMédecine interneRadiology
	Réadmission IsReadmission	Indicateur signalant si cet épisode représente un retour non planifié.
Descriptionn Un indicateur booléen identifiant si le patient est retourné à l'hôpital dans un délai défini (par exemple, 30 jours) après une sortie précédente. Cela contribue directement au le KPI 'Pourcentage de réadmissions non planifiées'. En filtrant sur cet attribut, les analystes peuvent approfondir les causes profondes des réadmissions et identifier des schémas dans les parcours de traitement initiaux. Pourquoi est-ce important ? : Facilite le KPI de taux de réadmission. Source des données : Calculé pendant l'ETL en comparant la date d'admission à la date de sortie précédente. Exemples truefaux
	Type d'épisode de soins EncounterType	La classification de la visite (par exemple, Visite au cabinet, Télésanté, Urgence).
Descriptionn Définit la modalité ou le cadre des soins fournis. Cela agit comme le 'Type de cas' dans les modèles de données génériques. Différents types d'épisodes de soins ont des flux et des exigences de facturation différents. Le filtrage par cet attribut est indispensable pour éviter de comparer des éléments incomparables dans l'analyse des temps de cycle. Pourquoi est-ce important ? : Distingue les différentes variantes de processus, telles que la télésanté ou les consultations en personne. Source des données : Champ 'encountertype' d'athenahealth. Exemples Visite au cabinetTélésantéUrgenceChirurgie
	Est un reprises IsRework	Indicateur signalant si cette activité est une répétition.
Descriptionn Un indicateur booléen qui est vrai si l'activité s'est produite plus d'une fois dans le même cas. Cela soutient le tableau de bord 'Fréquence des activités et boucles de reprise'. Il permet l'isolement immédiat des cas contenant du reprises, facilitant le calcul du KPI 'Fréquence des activités de reprises'. Pourquoi est-ce important ? : Identifie les inefficacités du processus et les étapes redondantes. Source des données : Calculé pendant l'ETL basé sur les occurrences d'activité par CaseId. Exemples truefaux
	Montant total facturé TotalChargeAmount	Le montant monétaire facturé pour l'activité ou l'épisode.
Descriptionn La valeur financière associée à l'activité ou le montant total de la réclamation. Cela permet le `Process Mining` basé sur les coûts et l'analyse de l'impact financier. Utilisé pour identifier les variations coûteuses dans les parcours de traitement et corréler l'efficacité des processus avec les résultats financiers. Pourquoi est-ce important ? : Ajoute une dimension financière à l'analyse des processus. Source des données : Champ 'amount' ou 'totalcharge' d'athenahealth dans les tables de réclamation/facturation. Exemples 150.002500.5045.00
	Statut du résultat diagnostique DiagnosticResultStatus	Le statut du résultat d'une commande diagnostique (par exemple, Positif, Normal).
Descriptionn Capture le résultat de haut niveau d'un test. Cela fournit un contexte pour le 'Délai d'exécution des tests diagnostiques' et les décisions de traitement ultérieures. Utilisé pour analyser si les résultats anormaux conduisent à des actions ultérieures plus rapides par rapport aux résultats normaux. Pourquoi est-ce important ? : Relie le flux de processus aux résultats cliniques. Source des données : Champs d'observation des résultats de laboratoire athenahealth. Exemples NormalAnormalCritique
	Statut du Sinistre ClaimStatus	Le statut de la réclamation financière associée aux soins.
Descriptionn Indique l'état de la demande de facturation, telle que 'Soumise', 'Refusée' ou 'Payée'. Ceci est pertinent pour l'activité 'Demande soumise' et le `débit` financier. Aide à identifier si des problèmes de documentation clinique entraînent des retards financiers en aval. Pourquoi est-ce important ? : Lie l'efficacité clinique à la performance du cycle de revenus. Source des données : Champ 'claimstatus' d'athenahealth. Exemples FACTURÉEN ATTENTEDROP
	Type de commande OrderType	Catégorie de la commande (par exemple, Laboratoire, Imagerie, Prescription).
Descriptionn Classe les commandes cliniques passées pendant l'épisode. Ceci est impératif pour le tableau de bord 'Délai d'exécution des tests diagnostiques'. Il permet aux analystes de mesurer les délais d'exécution spécifiquement pour les Laboratoires par rapport à l'Imagerie, qui ont souvent des accords de niveau de service et des points de blocage différents. Pourquoi est-ce important ? : Segmente le processus diagnostique pour une analyse spécifique du délai d'exécution. Source des données : Champ 'ordertype' ou 'class' d'athenahealth dans l'API des commandes. Exemples LaboratoireImageriePrescriptionProcédure

Obligatoire Recommandé Facultatif

Activités du parcours patient

Ce sont les étapes de processus et les jalons cruciaux à capturer dans votre `journal d'événements` pour une découverte et une optimisation précises de l'expérience patient.

7 Recommandé 8 Facultatif

	Activité	Descriptionn
	Diagnostic confirmé	Un clinicien attribue ou confirme officiellement un diagnostic pour l'état du patient lors de l'épisode de soins actuel. Cela peut être déduit de l'horodatage de création ou de 'dernière mise à jour' du code de diagnostic principal, tel que l'ICD-10, associé à l'épisode de soins du patient.
Pourquoi est-ce important ? : C'est une étape pivot qui dicte le parcours de traitement ultérieur. L'analyse des variations dans les activités après ce point aide à comprendre et à standardiser les protocoles de soins. Source des données : Déduit de la liste des problèmes du patient ou des données de diagnostic de la rencontre. Un changement ou une finalisation du code de diagnostic et de son `horodatage` associé signale cet événement. Capture Détecte l'horodatage lorsque le diagnostic principal de l'épisode de soins est ajouté ou mis à jour. Type d'événement inferred
	Évaluation initiale terminée	Marque l'achèvement de la première évaluation clinique, telle que le triage ou l'évaluation infirmière, où les signes vitaux et les plaintes principales sont enregistrés. Cet événement est souvent déduit du `horodatage` de la première note clinique signée ou d'un formulaire d'évaluation terminé pour la rencontre.
Pourquoi est-ce important ? : Ce jalon indique le début des soins cliniques. La durée entre l'enregistrement et cette activité est une mesure clé du temps d'attente initial du patient et de la réactivité des ressources. Source des données : Déduit du `horodatage` de création ou de signature de documents cliniques ou de feuilles de flux spécifiques dans athenaClinicals. Nécessite l'identification des types de documents pertinents pour le triage ou l'admission. Capture Identifier le premier `horodatage` sur une note clinique, une feuille de signes vitaux ou un formulaire d'admission spécifique pour la rencontre. Type d'événement inferred
	Ordre de sortie rédigé	Un médecin ou un prestataire autorisé rédige un ordre officiel de sortie du patient. Il s'agit d'un événement explicite et horodaté créé dans le module CPOE du DSE.
Pourquoi est-ce important ? : Cette activité initie le processus de sortie. Le temps entre cette commande et la sortie réelle est un indicateur clé de performance pour le 'Délai de planification des sorties'. Source des données : Situé dans la table des commandes. L'événement est identifié par un type de commande de 'Sortie' spécifique et son `horodatage` de création. Capture Un nouveau dossier avec un type de commande 'Sortie' est créé dans la table des commandes. Type d'événement explicit
	Patient enregistré	Cette activité signifie l'arrivée du patient et son enregistrement officiel pour son rendez-vous ou sa visite prévue. Ceci est généralement capturé comme un changement de statut explicite sur l'enregistrement du rendez-vous dans athenaClinicals ou athenaCommunicator.
Pourquoi est-ce important ? : C'est le début définitif du parcours sur site du patient. Il sert de point de départ essentiel pour mesurer les temps d'attente et le temps de cycle global d'une rencontre clinique. Source des données : Comptabilisé comme une mise à jour de statut dans les tables de rendez-vous ou de rencontres. Recherchez un statut 'Checked-In' (enregistré) et son `horodatage` correspondant. Capture Un changement de statut sur l'objet rendez-vous ou épisode de soins est enregistré avec un horodatage. Type d'événement explicit
	Patient sorti	Le patient est officiellement sorti, et la partie intra-établissement de son parcours est terminée. C'est le dernier événement ADT pour une rencontre hospitalière, capturé avec un `horodatage` précis.
Pourquoi est-ce important ? : Cet événement marque la fin du parcours principal du patient. C'est le point final pour mesurer le 'Temps de cycle du Parcours Patient' global et est indispensable pour l'analyse des réadmissions. Source des données : Il s'agit d'un événement explicite dans le système ADT ou la table des rencontres patient, marquant le statut final de la rencontre comme 'Sorti' avec un `horodatage`. Capture Le statut de la rencontre patient est mis à jour à 'Sorti' et un événement ADT est enregistré. Type d'événement explicit
	Procédure effectuée	Une procédure clinique, telle qu'une chirurgie ou une thérapie spécialisée, est effectuée sur le patient. Il s'agit d'un événement explicite capturé dans la documentationumentation clinique, souvent avec des heures de début et de fin spécifiques enregistrées dans une note de procédure.
Pourquoi est-ce important ? : Les procédures sont des étapes importantes dans le traitement d'un patient. L'analyse des activités avant et après une procédure aide à optimiser les `workflows` pré et post-opératoires. Source des données : Trouvé dans les notes de procédure ou les feuilles de suivi cliniques spécifiques d'athenaClinicals. L'horodatage de l'événement est dérivé de l'heure de début ou de fin documentée de la procédure. Capture Une note ou un journal de procédure est créé, contenant un horodatage de l'heure à laquelle la procédure a eu lieu. Type d'événement explicit
	Résultats du test reçus	Les résultats d'un test diagnostique sont finalisés et mis à disposition dans le dossier du patient. Ceci est généralement enregistré lorsque le système de laboratoire ou d'imagerie renvoie les résultats à athenahealth, créant une entrée horodatée.
Pourquoi est-ce important ? : La réception des résultats est un déclencheur critique pour les décisions cliniques ultérieures, telles que le diagnostic et la planification du traitement. Cet événement est le point final pour mesurer les délais d'exécution des diagnostics. Source des données : Situé dans la table des résultats ou des diagnostics, lié à la commande originale. L'événement est marqué par le `horodatage` lorsque le résultat a été classé ou reçu dans le dossier du patient. Capture Un nouveau dossier de résultat est créé avec un horodatage, souvent via une interface d'un SIL ou d'un RIS. Type d'événement explicit
	Médicament administré	Un médicament est physiquement administré au patient par le personnel clinique. Cela est enregistré explicitement dans le module Medication Administration Record (MAR) d'athenaClinicals, avec un horodatage précis pour chaque dose.
Pourquoi est-ce important ? : Cette activité représente une intervention thérapeutique directe. L'analyse de son timing aide à mesurer le 'Temps avant le premier traitement' et assure le respect des schémas de médication. Source des données : Trouvé dans les tables de données MAR. Chaque événement d'administration comprend un ID patient, un ID de médicament, un dosage et un horodatage d'administration. Capture Un enregistrement horodaté est créé dans le MAR chaque fois qu'un médicament est documenté comme administré. Type d'événement explicit
	Patient transféré	Le patient est déplacé d'une unité de soins ou d'un département à un autre, par exemple du service des urgences à une unité d'hospitalisation. Ceci est capturé explicitement via un événement Admission, Sortie, Transfert (ADT) dans le DME.
Pourquoi est-ce important ? : Cette activité est indispensablele pour analyser les passations départementales et le flux patient au sein d'une installation. Elle aide à identifier les points de blocage dans le 'Temps de passation patient' et l'allocation des ressources. Source des données : Comptabilisé dans le `journal d'événements` ADT ou les tables de suivi des patients. Chaque événement de transfert inclut le patient, les lieux de départ/d'arrivée et un `horodatage`. Capture Un message ADT ou une entrée de journal d'événements est généré avec un horodatage lors du transfert du patient. Type d'événement explicit
	Plan de traitement élaboré	Représente la création et la documentation formelles du plan de traitement d'un patient par un clinicien. Cela peut être enregistré comme la création ou la signature d'un document spécifique 'Plan de soins' ou d'un ensemble d'ordres de traitement connexes.
Pourquoi est-ce important ? : Cette activité formalise le parcours clinique prévu. C'est un point clé pour mesurer la conformité aux protocoles standard et analyser les variations de soins. Source des données : Probablement trouvé dans les documents cliniques ou les tables d'ordres. Cet événement correspond au `horodatage` d'une note de plan de soins signée ou à la soumission d'un ensemble coordonné d'ordres de traitement. Capture L'événement est l'horodatage de création ou de finalisation d'un document de plan de traitement spécifique ou d'un ensemble de commandes. Type d'événement explicit
	Rendez-vous de suivi programmé	Un rendez-vous de suivi est programmé pour le patient après son traitement principal ou sa sortie. Cet événement est explicitement capturé lorsqu'un nouveau rendez-vous est créé dans le module de planification athenaCommunicator.
Pourquoi est-ce important ? : Cette activité est indispensablele pour comprendre la coordination des soins post-sortie et son impact sur des résultats tels que les taux de réadmission. Elle témoigne de la continuité des soins. Source des données : Comptabilisé dans la table des rendez-vous. L'événement est identifié par un `horodatage` de création pour un rendez-vous qui a lieu après la date de sortie. Capture Un nouveau dossier de rendez-vous est créé dans le système de planification. Type d'événement explicit
	Rendez-vous programmé	Représente la prise de rendez-vous pour un patient. Cet événement est explicitement enregistré lorsqu'un utilisateur crée et confirme une nouvelle entrée de rendez-vous dans le module de planification d'athenahealth, athenaCommunicator.
Pourquoi est-ce important ? : Cette activité marque le point d'engagement initial pour de nombreux parcours patients. L'analyse du temps entre la planification et l'enregistrement aide à comprendre l'accès des patients et l'efficacité avant la visite. Source des données : Il s'agit d'un événement explicite enregistré dans les tables de rendez-vous ou de planification. Il est généralement associé à un `horodatage` de création et à un ID patient. Capture L'événement est enregistré lors de la création d'un dossier de rendez-vous dans le module de planification. Type d'événement explicit
	Sinistre Déclaré	Une demande de remboursement pour les services rendus lors de l'épisode de soins du patient est générée et soumise au payeur. Il s'agit d'un événement explicite au sein du module de gestion du cycle de revenus athenaCollector.
Pourquoi est-ce important ? : Bien qu'il s'agisse d'une étape administrative, cette activité est indispensablele pour analyser le processus du cycle de revenus qui se déroule parallèlement au parcours clinique. Elle aide à identifier les retards entre les soins cliniques et la facturation. Source des données : Trouvé dans les tables de réclamations ou de facturation. L'événement est marqué par un horodatage de création ou de soumission de réclamation. Capture Un dossier de réclamation est créé et son statut est mis à jour à 'Soumise' avec un horodatage. Type d'événement explicit
	Spécimen prélevé	Représente l'événement où un spécimen biologique, tel que du sang ou de l'urine, est prélevé sur le patient pour un test de laboratoire. Il s'agit généralement d'un événement explicite enregistré dans le module de laboratoire ou comme une mise à jour du statut de la commande.
Pourquoi est-ce important ? : C'est une étape clé au sein du processus de test diagnostique. Le temps entre la commande, le prélèvement et les résultats peut révéler des points de blocage significatifs dans les `workflows` de laboratoire. Source des données : Cet événement peut être trouvé comme un changement de statut sur la commande de laboratoire ou comme un événement distinct dans un système d'information de laboratoire interfacé avec athenahealth. Recherchez un statut 'Collected' (collecté) et un `horodatage`. Capture Comptabilisé comme une mise à jour du statut de la commande de laboratoire ou dans un module dédié de suivi des échantillons. Type d'événement explicit
	Test diagnostique commandé	Un prestataire place une commande pour un examen diagnostique tel qu'une analyse de laboratoire, un examen d'imagerie ou une autre procédure. Il s'agit d'un événement explicite et horodaté créé via la fonctionnalité CPOE (Computerized Provider Order Entry) dans athenaClinicals.
Pourquoi est-ce important ? : C'est un point de décision critique qui initie un sous-processus diagnostique. Le suivi de cette activité est indispensable pour analyser le KPI 'Délai d'exécution du test diagnostique' de la commande au résultat. Source des données : Trouvé dans la table des commandes. Chaque commande aura un identifiant patient, un nom de commande, un statut de commande et un horodatage de création. Capture Un nouveau dossier est créé dans la table des commandes du système avec un horodatage. Type d'événement explicit

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données d'athenahealth

Étapes

Connectez-vous au portail athenaNet avec vos identifiants sécurisés.
Naviguez vers le module Rapports via le menu principal, généralement sous 'Rapports' > 'Générateur de rapports' ou 'Rapports personnalisés'.
Cliquez sur 'Créer un nouveau rapport' et sélectionnez 'Épisodes de soins' ou 'Visite patient' comme catégorie de rapport principale. Cela garantit que les données granulaires sont centrées sur l'épisode patient spécifique.
Dans la zone de sélection 'Colonnes' ou 'Champs', recherchez et ajoutez l'Identifiant Patient (Patient ID) et l'Identifiant d'Épisode de Soins (Encounter ID) pour servir d'Identifiant de Cas.
Ajoutez les colonnes démographiques et contextuelles requises pour les attributs, telles que le Département, le Nom du Prestataire, l'Âge du Patient et le Code de Diagnostic Principal.
Ajoutez les colonnes d'horodatage spécifiques correspondant aux activités. Vous devrez peut-être regarder dans différents groupes de champs (par exemple, 'Planification' pour Rendez-vous programmé, 'Enregistrement' pour Heure d'enregistrement, 'Facturation' pour Réclamation soumise). Assurez-vous de sélectionner les formats 'Date et Heure' là où ils sont disponibles, pas seulement la Date.
Appliquez des filtres à la configuration du rapport. Définissez la plage de 'Date d'épisode de soins' sur votre fenêtre d'analyse souhaitée (par exemple, les 6 derniers mois) et filtrez les rendez-vous 'Annulés' ou 'Non-présentés' pour vous concentrer sur les parcours terminés.
Cliquez sur 'Exécuter le rapport' pour prévisualiser les données. Vérifiez que les colonnes contiennent des données et ne sont pas entièrement nulles.
Sélectionnez l'option 'Exporter' et choisissez 'CSV' (Comma Separated Values) comme format. N'utilisez pas les fonctionnalités de formatage Excel/XLSX car elles compliquent le traitement.
Enregistrez le fichier localement sous 'athena_raw_export.csv'.
Étant donné que le rapport exporte une ligne par épisode de soins avec plusieurs colonnes de date (format large), vous devez le remodeler en un journal d'événements (format long). Utilisez le script Python fourni dans la section Requête pour effectuer cette transformation.
Exécutez le script pour générer le fichier final 'process_mining_event_log.csv' et téléchargez ce fichier dans ProcessMind.

Configuration

Catégorie de rapport: Choisissez 'Encounter Activity' ou 'Clinicals' comme catégorie de base pour capturer la majorité des étapes du workflow clinique.
Plage de dates: Limitez l'extraction initiale à 3-6 mois pour éviter les délais d'attente de rapport ou les limites de lignes (généralement plafonnées à environ 50 000 lignes dans les vues standard).
Sélection de colonnes: Assurez-vous que les champs d'horodatage explicites sont sélectionnés. Évitez les champs calculés comme 'Jours depuis l'enregistrement' au profit de 'Date/Heure d'enregistrement' absolue.
Gestion des valeurs nulles: Configurez le rapport pour afficher des cellules vides pour les données manquantes plutôt que du texte personnalisé comme 'N/A' afin de faciliter le traitement par script.
Filtrage par département: Si l'organisation est grande, filtrez par Sites de service ou Départements spécifiques (par exemple, 'Cardiology', 'Orthopedics') pour maintenir l'ensemble de données ciblé.
Permissions: L'utilisateur doit disposer des permissions 'Report Creator' ou 'Clinical Reporting' dans athenaNet pour accéder au Générateur de rapports personnalisés.

a Exemple de requête config

import pandas as pd
import numpy as np
from datetime import datetime

# Configuration: Input and Output filenames
INPUT_FILE = 'athena_raw_export.csv'
OUTPUT_FILE = 'patient_journey_event_log.csv'

# Load the raw wide-format report from athenaNet
# Assumes standard CSV export. Adjust encoding if necessary (e.g., 'utf-8-sig' or 'latin1')
df = pd.read_csv(INPUT_FILE, dtype=str)

# Define the mapping between Activity Names and the columns in your athenaNet report
# You must ensure these column names match your Report Builder export headers exactly
activity_mapping = {
    'Appointment Scheduled': 'APPT_CREATED_TIMESTAMP',
    'Patient Checked In': 'CHECKIN_TIMESTAMP',
    'Initial Assessment Completed': 'INTAKE_COMPLETED_TIMESTAMP',
    'Diagnostic Test Ordered': 'ORDER_ENTRY_TIMESTAMP',
    'Specimen Collected': 'LAB_COLLECTION_TIMESTAMP',
    'Test Results Received': 'LAB_RESULT_TIMESTAMP',
    'Diagnosis Confirmed': 'DIAGNOSIS_ENTRY_TIMESTAMP',
    'Treatment Plan Developed': 'PLAN_NOTE_TIMESTAMP',
    'Medication Administered': 'MED_ADMIN_TIMESTAMP',
    'Procedure Performed': 'PROCEDURE_END_TIMESTAMP',
    'Patient Transferred': 'TRANSFER_TIMESTAMP',
    'Discharge Order Written': 'DISCHARGE_ORDER_TIMESTAMP',
    'Patient Discharged': 'DISCHARGE_TIMESTAMP',
    'Follow-Up Appointment Scheduled': 'NEXT_APPT_CREATED_TIMESTAMP',
    'Claim Submitted': 'CLAIM_SUBMISSION_TIMESTAMP'
}

# Define attribute columns to carry over to every event row
attribute_columns = {
    'ENCOUNTER_ID': 'PatientEpisodeId',
    'PATIENT_ID': 'PatientId',
    'PROVIDER_NAME': 'ProviderName',
    'DEPARTMENT_NAME': 'DepartmentName',
    'PRIMARY_DIAGNOSIS_CODE': 'PrimaryDiagnosisCode',
    'PATIENT_AGE': 'PatientAgeGroup',
    'ENCOUNTER_TYPE': 'EncounterType',
    'DISCHARGE_DISPOSITION': 'DischargeDisposition',
    'IS_READMISSION': 'IsReadmission'
}

# Initialize list to hold event rows
event_log_data = []

# Transformation Loop
for index, row in df.iterrows():
    episode_id = row.get('ENCOUNTER_ID')
    
    # Skip rows without a valid identifier
    if pd.isna(episode_id) or str(episode_id).strip() == '':
        continue

    # Iterate through each defined activity
    for activity_name, col_name in activity_mapping.items():
        timestamp_val = row.get(col_name)
        
        # Only create an event if a valid timestamp exists
        if pd.notna(timestamp_val) and str(timestamp_val).strip() != '':
            
            # Create base event object
            event = {
                'PatientEpisodeId': episode_id,
                'ActivityName': activity_name,
                'EventTimestamp': timestamp_val,
                'SourceSystem': 'athenahealth',
                'LastDataUpdate': datetime.now().strftime('%Y-%m-%d %H:%M:%S')
            }
            
            # Add attributes
            for csv_col, target_col in attribute_columns.items():
                event[target_col] = row.get(csv_col, None)
            
            event_log_data.append(event)

# Create DataFrame from the list of events
event_log_df = pd.DataFrame(event_log_data)

# Standardize Date Format (ISO 8601 Recommended)
# Adjust the format string matches the raw CSV format (e.g., '%m/%d/%Y %H:%M')
event_log_df['EventTimestamp'] = pd.to_datetime(event_log_df['EventTimestamp'], errors='coerce')

# Remove rows where timestamp parsing failed
event_log_df = event_log_df.dropna(subset=['EventTimestamp'])

# Sort by Episode and Time
event_log_df = event_log_df.sort_values(by=['PatientEpisodeId', 'EventTimestamp'])

# Output to CSV
event_log_df.to_csv(OUTPUT_FILE, index=False)

print(f"Transformation complete. Processed {len(df)} encounters into {len(event_log_df)} events.")
print(f"File saved to: {OUTPUT_FILE}")

Étapes

Enregistrer l'application API: Connectez-vous au Portail Développeur athenahealth et enregistrez une nouvelle application pour obtenir votre Client ID et votre Secret Client. Assurez-vous que l'application dispose des scopes pour les rendez-vous, les données cliniques (dossiers), les commandes et la facturation (réclamations).
Configurer l'environnement Python: Installez les bibliothèques Python requises (requests, pandas) dans votre environnement d'exécution en utilisant pip install requests pandas.
Authentification: Implémentez le flux d'octroi des informations d'identification client OAuth 2.0 pour récupérer un jeton d'accès. Ce jeton doit être inclus dans l'en-tête d'autorisation (Bearer token) de tous les appels API ultérieurs.
Définir la portée: Définissez l'ID de la pratique et la plage de dates pour l'extraction. Les API athenahealth sont spécifiques à la pratique, vous devez donc itérer sur les ID de pratique si vous en gérez plusieurs.
Extraire les rendez-vous: Interrogez l'endpoint /appointments/booked ou /appointments/changed pour récupérer les épisodes de soins de base. Mappez l'ID de rendez-vous au PatientEpisodeId. Extrayez 'Rendez-vous programmé' de la date de création et 'Patient enregistré' de l'heure d'enregistrement.
Itérer les épisodes de soins pour les événements cliniques: Pour chaque ID de rendez-vous (épisode de soins), interrogez les sous-endpoints cliniques. Appelez /chart/{encounterId}/vitals pour 'Évaluation initiale terminée'. Appelez /chart/{encounterId}/orders pour 'Test diagnostique commandé', 'Échantillon collecté' (basé sur le statut) et 'Ordre de sortie rédigé'.
Récupérer les résultats et les diagnostics: Interrogez /chart/{encounterId}/analyteresults ou /chart/{encounterId}/labresults pour 'Résultats des tests reçus'. Interrogez /chart/{encounterId}/diagnoses pour 'Diagnostic confirmé'.
Extraire les traitements et les procédures: Interrogez /chart/{encounterId}/plan pour 'Plan de traitement développé'. Interrogez /chart/{encounterId}/procedures pour 'Procédure effectuée'. Interrogez /chart/{encounterId}/medications/admin pour 'Médicament administré'.
Identifier les événements ADT et les réclamations: Utilisez l'historique du statut des rendez-vous ou des endpoints hospitaliers spécifiques (si disponibles) pour capturer 'Patient transféré' et 'Patient sorti'. Interrogez /claims liés au rendez-vous pour extraire 'Réclamation soumise'.
Lier les suivis: Identifiez 'Rendez-vous de suivi programmé' en recherchant les rendez-vous ultérieurs créés pour le même ID patient dans le délai de l'épisode de soins.
Transformer et aplatir: Analysez les réponses JSON imbriquées en une liste plate de dictionnaires d'événements. Convertissez tous les horodatages au format ISO 8601. Mappez les champs vers (ActivityName), PatientEpisodeId et EventHorodatage.
Exporter les données: Chargez la liste des dictionnaires dans un DataFrame pandas, effectuez un nettoyage final (gestion des valeurs nulles) et exportez vers un fichier CSV prêt pour l'ingestion par ProcessMind.

Configuration

API Credentials: Nécessite un Client ID et un Secret valides du Portail Développeur athenahealth avec un accès en production.
Practice ID: L'identifiant numérique unique pour le contexte de la pratique médicale. Le script doit être exécuté par pratique si l'extraction est effectuée pour un réseau.
Plage de dates: Une fenêtre d'extraction de 3 à 6 mois est recommandée en raison du volume de données cliniques granulaires.
Rate Limiting: L'API athenaOne a des limites de taux strictes (par exemple, 5 appels par seconde). Le script inclut une fonction de temporisation, mais les extractions à l'échelle de l'entreprise devraient implémenter un backoff exponentiel.
Scopes: Assurez-vous que le jeton dispose des scopes pour athena/service/Athenanet.MDP.* ou des scopes granulaires spécifiques pour les rendez-vous, les dossiers médicaux et les données financières.
Pagination: La plupart des endpoints renvoient un nombre limité d'enregistrements (1000 par défaut). Le script doit gérer les paramètres next ou offset.
Filtrage par département: Si vous analysez des flux spécifiques (par exemple, Urgences vs. Ambulatoire), filtrez par ID de département pendant la phase de récupération des rendez-vous.

a Exemple de requête python

import requests
import pandas as pd
import time
from datetime import datetime, timedelta
import base64

class=class="hl-string">"hl-comment"># Configuration
API_KEY = class="hl-string">'YOUR_CLIENT_ID'
API_SECRET = class="hl-string">'YOUR_CLIENT_SECRET'
PRACTICE_ID = class="hl-string">'195900'  class=class="hl-string">"hl-comment"># Replace with your Practice ID
BASE_URL = class="hl-string">'https://api.athenahealth.com/preview1'  class=class="hl-string">"hl-comment"># Use production URL for live data
START_DATE = class="hl-string">'01/01/2023'
END_DATE = class="hl-string">'01/31/2023'
OUTPUT_FILE = class="hl-string">'athena_patient_journey.csv'

def get_access_token():
    url = fclass="hl-string">'{BASE_URL}/oauth2/v1/token'
    auth_str = fclass="hl-string">'{API_KEY}:{API_SECRET}'
    b64_auth = base64.b64encode(auth_str.encode()).decode()
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Basic {b64_auth}',
        class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'
    }
    data = {class="hl-string">'grant_type': class="hl-string">'client_credentials', class="hl-string">'scope': class="hl-string">'athena/service/Athenanet.MDP.*'}
    response = requests.post(url, headers=headers, data=data)
    if response.status_code == 200:
        return response.json()[class="hl-string">'access_token']
    else:
        raise Exception(fclass="hl-string">'Auth failed: {response.text}')

def fetch_paginated(url, headers, params):
    results = []
    while True:
        response = requests.get(url, headers=headers, params=params)
        if response.status_code == 429:
            time.sleep(2)
            continue
        if response.status_code != 200:
            print(fclass="hl-string">'Error fetching {url}: {response.status_code}')
            break
        data = response.json()
        if class="hl-string">'totalcount' in data and data[class="hl-string">'totalcount'] == 0:
            break
        class=class="hl-string">"hl-comment"># Handle different response structures (key might be appointments, orders, etc.)
        keys = [k for k in data.keys() if k not in [class="hl-string">'totalcount', class="hl-string">'next', class="hl-string">'previous']]
        if keys:
            results.extend(data[keys[0]])
        
        if class="hl-string">'next' in data and data[class="hl-string">'next']:
             class=class="hl-string">"hl-comment"># Athena pagination often uses offset or a link
             class=class="hl-string">"hl-comment"># Adjust based on specific endpoint logic if next is not a full URL
             params[class="hl-string">'offset'] = params.get(class="hl-string">'offset', 0) + len(data[keys[0]])
        else:
            break
    return results

def extract_events():
    token = get_access_token()
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}'}
    events = []

    class=class="hl-string">"hl-comment"># 1. Fetch Appointments (Patient Episodes)
    class=class="hl-string">"hl-comment"># Using /appointments/booked for the range
    print(class="hl-string">'Fetching appointments...')
    appt_params = {
        class="hl-string">'startdate': START_DATE,
        class="hl-string">'enddate': END_DATE,
        class="hl-string">'showclaimdetail': class="hl-string">'true',  class=class="hl-string">"hl-comment"># optimize to get claim info early
        class="hl-string">'ignorepartners': class="hl-string">'true'
    }
    appointments = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/appointments/booked', headers, appt_params)

    for appt in appointments:
        episode_id = str(appt.get(class="hl-string">'appointmentid'))
        patient_id = appt.get(class="hl-string">'patientid')
        dept_id = appt.get(class="hl-string">'departmentid')
        provider_id = appt.get(class="hl-string">'providerid')
        
        class=class="hl-string">"hl-comment"># Base Activity: Appointment Scheduled
        if appt.get(class="hl-string">'date'): class=class="hl-string">"hl-comment"># capturing creation/scheduled date requires parsing history or booking info
            class=class="hl-string">"hl-comment"># Fallback to date if created date unavailable, but typically we want class="hl-string">'scheduleddatetime'
            sched_time = appt.get(class="hl-string">'scheduleddatetime', appt.get(class="hl-string">'date') + class="hl-string">' ' + appt.get(class="hl-string">'starttime'))
            events.append({
                class="hl-string">'PatientEpisodeId': episode_id,
                class="hl-string">'ActivityName': class="hl-string">'Appointment Scheduled',
                class="hl-string">'EventTimestamp': sched_time,
                class="hl-string">'SourceSystem': class="hl-string">'athenaOne',
                class="hl-string">'PatientId': patient_id,
                class="hl-string">'DepartmentName': dept_id
            })

        class=class="hl-string">"hl-comment"># Activity: Patient Checked In
        if appt.get(class="hl-string">'startcheckin'):
            events.append({
                class="hl-string">'PatientEpisodeId': episode_id,
                class="hl-string">'ActivityName': class="hl-string">'Patient Checked In',
                class="hl-string">'EventTimestamp': appt.get(class="hl-string">'date') + class="hl-string">' ' + appt.get(class="hl-string">'startcheckin'), class=class="hl-string">"hl-comment"># combining date and time
                class="hl-string">'SourceSystem': class="hl-string">'athenaOne',
                class="hl-string">'PatientId': patient_id
            })
            
        class=class="hl-string">"hl-comment"># Activity: Patient Discharged (Ambulatory Checkout)
        if appt.get(class="hl-string">'stopcheckin'):
            events.append({
                class="hl-string">'PatientEpisodeId': episode_id,
                class="hl-string">'ActivityName': class="hl-string">'Patient Discharged',
                class="hl-string">'EventTimestamp': appt.get(class="hl-string">'date') + class="hl-string">' ' + appt.get(class="hl-string">'stopcheckin'),
                class="hl-string">'SourceSystem': class="hl-string">'athenaOne',
                class="hl-string">'PatientId': patient_id,
                class="hl-string">'DischargeDisposition': class="hl-string">'Home' class=class="hl-string">"hl-comment"># Default for ambulatory
            })

        class=class="hl-string">"hl-comment"># Activity: Claim Submitted
        if class="hl-string">'claimid' in appt:
             class=class="hl-string">"hl-comment"># Ideally query /claims/{claimId} for exact submission timestamp
             class=class="hl-string">"hl-comment"># Using appointment date as proxy if detailed claim fetch skipped
             class=class="hl-string">"hl-comment"># Here we assume we fetch claim details:
             claim_res = requests.get(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/claims/{appt["claimid"]}', headers=headers)
             if claim_res.status_code == 200:
                 claim_data = claim_res.json()
                 if claim_data.get(class="hl-string">'billedservicedate'):
                     events.append({
                        class="hl-string">'PatientEpisodeId': episode_id,
                        class="hl-string">'ActivityName': class="hl-string">'Claim Submitted',
                        class="hl-string">'EventTimestamp': claim_data.get(class="hl-string">'createddate', claim_data.get(class="hl-string">'billedservicedate')) + class="hl-string">' 12:00:00',
                        class="hl-string">'SourceSystem': class="hl-string">'athenaCollector',
                        class="hl-string">'PatientId': patient_id
                     })

        class=class="hl-string">"hl-comment"># Clinical Data Extraction (Requires Encounter Context)
        encounter_id = appt.get(class="hl-string">'encounterid')
        if encounter_id:
            class=class="hl-string">"hl-comment"># Activity: Initial Assessment (Vitals)
            vitals = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/vitals', headers, {})
            if vitals:
                class=class="hl-string">"hl-comment"># Take the first vital sign entry time
                first_vital = sorted(vitals, key=lambda x: x.get(class="hl-string">'date') or class="hl-string">'')[0]
                events.append({
                    class="hl-string">'PatientEpisodeId': episode_id,
                    class="hl-string">'ActivityName': class="hl-string">'Initial Assessment Completed',
                    class="hl-string">'EventTimestamp': first_vital.get(class="hl-string">'date') + class="hl-string">' ' + (first_vital.get(class="hl-string">'time') or class="hl-string">'00:00'),
                    class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals',
                    class="hl-string">'PatientId': patient_id
                })

            class=class="hl-string">"hl-comment"># Activity: Diagnoses
            diagnoses = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/diagnoses', headers, {})
            for diag in diagnoses:
                events.append({
                    class="hl-string">'PatientEpisodeId': episode_id,
                    class="hl-string">'ActivityName': class="hl-string">'Diagnosis Confirmed',
                    class="hl-string">'EventTimestamp': diag.get(class="hl-string">'lastmodifieddatetime', appt.get(class="hl-string">'date') + class="hl-string">' 12:00:00'),
                    class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals',
                    class="hl-string">'PrimaryDiagnosisCode': diag.get(class="hl-string">'diagnosiscode')
                })

            class=class="hl-string">"hl-comment"># Activity: Orders (Labs, Procedures, Discharge)
            orders = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/orders', headers, {})
            for order in orders:
                order_type = order.get(class="hl-string">'documentationtype', class="hl-string">'')
                created_time = order.get(class="hl-string">'createddatetime', appt.get(class="hl-string">'date') + class="hl-string">' 12:00:00')
                
                if class="hl-string">'LAB' in order_type.upper() or class="hl-string">'IMAGING' in order_type.upper():
                    events.append({
                        class="hl-string">'PatientEpisodeId': episode_id,
                        class="hl-string">'ActivityName': class="hl-string">'Diagnostic Test Ordered',
                        class="hl-string">'EventTimestamp': created_time,
                        class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                    })
                    class=class="hl-string">"hl-comment"># Activity: Specimen Collected (Inferred from status or specific fields if available)
                    if order.get(class="hl-string">'status') in [class="hl-string">'COMPLETED', class="hl-string">'REVIEW']:
                         events.append({
                            class="hl-string">'PatientEpisodeId': episode_id,
                            class="hl-string">'ActivityName': class="hl-string">'Specimen Collected',
                            class="hl-string">'EventTimestamp': order.get(class="hl-string">'lastmodifieddatetime', created_time), class=class="hl-string">"hl-comment"># Approximation
                            class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                        })
                
                if class="hl-string">'SURGERY' in order_type.upper() or class="hl-string">'PROCEDURE' in order_type.upper():
                     events.append({
                        class="hl-string">'PatientEpisodeId': episode_id,
                        class="hl-string">'ActivityName': class="hl-string">'Procedure Performed',
                        class="hl-string">'EventTimestamp': order.get(class="hl-string">'performdate', created_time),
                        class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                    })

                if class="hl-string">'DISCHARGE' in order_type.upper():
                    events.append({
                        class="hl-string">'PatientEpisodeId': episode_id,
                        class="hl-string">'ActivityName': class="hl-string">'Discharge Order Written',
                        class="hl-string">'EventTimestamp': created_time,
                        class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                    })

            class=class="hl-string">"hl-comment"># Activity: Test Results Received
            results = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/analyteresults', headers, {})
            for res in results:
                events.append({
                    class="hl-string">'PatientEpisodeId': episode_id,
                    class="hl-string">'ActivityName': class="hl-string">'Test Results Received',
                    class="hl-string">'EventTimestamp': res.get(class="hl-string">'analytedatetime', appt.get(class="hl-string">'date') + class="hl-string">' 12:00:00'),
                    class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                })

            class=class="hl-string">"hl-comment"># Activity: Treatment Plan
            class=class="hl-string">"hl-comment"># Check for Care Plan document or assessment note
            notes = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/progressnotes', headers, {})
            if notes:
                 events.append({
                    class="hl-string">'PatientEpisodeId': episode_id,
                    class="hl-string">'ActivityName': class="hl-string">'Treatment Plan Developed',
                    class="hl-string">'EventTimestamp': notes[0].get(class="hl-string">'lastmodifieddatetime', appt.get(class="hl-string">'date') + class="hl-string">' 12:00:00'),
                    class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                })

            class=class="hl-string">"hl-comment"># Activity: Medication Administered
            class=class="hl-string">"hl-comment"># Look for administration records
            meds = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/medications', headers, {})
            for med in meds:
                 if med.get(class="hl-string">'events'): class=class="hl-string">"hl-comment"># Check if administration events exist
                     for event in med[class="hl-string">'events']:
                         if event.get(class="hl-string">'type') == class="hl-string">'ADMINISTERED':
                             events.append({
                                class="hl-string">'PatientEpisodeId': episode_id,
                                class="hl-string">'ActivityName': class="hl-string">'Medication Administered',
                                class="hl-string">'EventTimestamp': event.get(class="hl-string">'eventdate'),
                                class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                             })

            class=class="hl-string">"hl-comment"># Activity: Patient Transferred (Inferred from Hospital Stay/ADT data if available)
            class=class="hl-string">"hl-comment"># Mocking logic: If department ID changes in encounter history (requires fetching history)
            class=class="hl-string">"hl-comment"># For standard API, we check if class="hl-string">'admissionstatus' indicates transfer
            pass class=class="hl-string">"hl-comment"># Complexity high for standard extraction without Hospital scope

            class=class="hl-string">"hl-comment"># Activity: Follow-Up Appointment Scheduled
            class=class="hl-string">"hl-comment"># We check if this patient has a FUTURE appointment created around this time
            class=class="hl-string">"hl-comment"># This requires a separate query or processing the full appointment list post-loop
            class=class="hl-string">"hl-comment"># Simplified: Logic placeholder
            pass 

    class=class="hl-string">"hl-comment"># Post-processing for Follow-Ups (simplified)
    class=class="hl-string">"hl-comment"># Sort all appts by patient and date, check next appt creation date
    
    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(events)
    df[class="hl-string">'LastDataUpdate'] = datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Final Validation and Export
    if not df.empty:
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
        df.sort_values(by=[class="hl-string">'PatientEpisodeId', class="hl-string">'EventTimestamp'], inplace=True)
        df.to_csv(OUTPUT_FILE, index=False)
        print(fclass="hl-string">'Successfully exported {len(df)} rows to {OUTPUT_FILE}')
    else:
        print(class="hl-string">'No events extracted.')

if __name__ == class="hl-string">'__main__':
    extract_events()

Votre modèle de données du Parcours Patient

Votre modèle de données du Parcours Patient

Attributs du parcours patient

Activités du parcours patient

Guides d'extraction

Export CSV personnalisé du Générateur de rapports athenaNet

Étapes

Configuration

a Exemple de requête config

Extraction d'événements de l'API athenaOne avec Python

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Optimisez votre Parcours Patient maintenant, éliminez les points de blocage

Votre modèle de données du Parcours Patient

Votre modèle de données du Parcours Patient

Attributs du parcours patient

Activités du parcours patient

Guides d'extraction

Export CSV personnalisé du Générateur de rapports athenaNet

Étapes

Configuration

a Exemple de requête config

Extraction d'événements de l'API athenaOne avec Python

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Optimisez votre Parcours Patient maintenant, éliminez les points de blocage