> Amélioration continue des processus > Parcours patient > athenahealth > Modèle de données

Votre modèle de données pour le parcours patient

athenahealth

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

Votre modèle de données pour le parcours patient

Ce modèle vous guide dans la collecte des données nécessaires à l’analyse du parcours patient. Il présente les attributs et les activités à suivre, ainsi que des instructions claires pour extraire ces informations d’athenahealth. Utilisez cette ressource pour préparer vos données à l’analyse Process Mining.

Attributs recommandés à collecter
Activités clés à suivre
Guide d’extraction des données d’athenahealth

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du parcours patient

Voici les champs de données recommandés à inclure dans votre journal d’événements. Ils sont essentiels pour analyser et comprendre les parcours des patients dans leur ensemble.

5 Obligatoire 9 Recommandé 5 Facultatif

	Nom	Description
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière extraction ou actualisation des données.
Description Indique si les données utilisées dans l’analyse sont à jour. Les utilisateurs peuvent ainsi savoir s’ils consultent des données en temps réel ou un instantané historique. Cet attribut sert à gérer les pipelines de données et à vérifier que les Dashboards reflètent l’état le plus récent du processus. Pourquoi est-ce important ? Essentiel à la gouvernance des données et à la confiance des utilisateurs dans l’actualité des informations du Dashboard. Où trouver ces 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 de soins du patient PatientEpisodeId	Identifiant unique de l’épisode de soins ou du parcours du patient.
Description Cet attribut sert d’identifiant central du cas et regroupe toutes les activités liées à une période de soins ou à une affection donnée. Il relie des événements distincts, comme les rendez-vous, les demandes d’examens diagnostiques et les procédures de sortie, au sein d’un même parcours. Dans l’analyse, cet identifiant est la clé principale du Process Mining et permet de reconstituer le flux de bout en bout. Il garantit que plusieurs visites d’un même patient pour des affections différentes sont traitées comme des instances de processus distinctes. Pourquoi est-ce important ? Indispensable pour définir le périmètre d’une instance de processus dans l’analyse. Où trouver ces données Obtenu en regroupant les identifiants de consultation ou associé à un identifiant d’épisode de soins spécifique dans athenahealth. Exemples EP-2023-88491EP-2023-99102ENC-55412-GRP
	Horodatage de l’événement EventTimestamp	Date et heure précises auxquelles l’activité a eu lieu.
Description Enregistre le moment exact où une activité s’est déroulée. Cette information permet de classer les événements par ordre chronologique et de calculer la durée entre les étapes. Elle est essentielle aux analyses temporelles, notamment au temps de cycle, aux temps d’attente et au débit. Une grande précision est préférable pour déterminer l’ordre des événements survenus le même jour. Pourquoi est-ce important ? Nécessaire pour ordonner les événements et calculer tous les indicateurs temporels. Où trouver ces données Champs d’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	Nom de l’événement ou de la tâche effectuée dans le parcours du patient.
Description Indique l’étape précise du processus, par exemple « Patient enregistré », « Examen diagnostique prescrit » ou « Médicament administré ». Cette chaîne de texte définit les nœuds de la cartographie du processus. Elle sert à visualiser le flux du processus et à repérer l’ordre des opérations. Il est essentiel de normaliser ces noms pour obtenir une cartographie lisible, sans regroupements automatiques. Pourquoi est-ce important ? Définit les étapes de la cartographie du processus et est indispensable au Process Mining. Où trouver ces données Issu des journaux d’audit, des changements de statut des rendez-vous ou des descriptions des lignes de facturation. Exemples Rendez-vous planifiéPatient enregistré à son arrivéeExamen diagnostique prescritPatient sorti
	Système source SourceSystem	Nom du système d’où proviennent les données.
Description Identifie le système informatique qui a généré l’enregistrement, ici « athenahealth ». Cet attribut est particulièrement utile dans les environnements comportant plusieurs systèmes, où les données peuvent être combinées. Il permet aux analystes de filtrer la vue par source de données et de rechercher les problèmes de qualité propres à un système. Pourquoi est-ce important ? Fournit la traçabilité des données et leur contexte dans les environnements de Process Mining faisant intervenir plusieurs systèmes. Où trouver ces données Valeur littérale codée en dur ou identifiant de configuration du système. Exemples athenahealthAthenaOneAthenaPractice
	Code du diagnostic principal PrimaryDiagnosisCode	Code CIM-10 principal associé à l’épisode.
Description Classe le motif clinique du parcours du patient. Il fournit le contexte nécessaire à la comparaison des parcours par tranche d’âge et diagnostic. Les analystes s’en servent pour segmenter les parcours par affection, par exemple une pneumonie ou une fracture, car les parcours et les temps de cycle attendus varient considérablement selon le diagnostic. Pourquoi est-ce important ? Permet de comparer des cas similaires, car les temps de cycle varient fortement selon le diagnostic. Où trouver ces données Champs de diagnostic des consultations ou des demandes de remboursement (CIM-10). Exemples J18.9I10E11.9
	Destination à la sortie DischargeDisposition	Destination ou statut du patient au moment de sa sortie.
Description Indique où le patient s’est rendu après l’épisode, par exemple à son domicile, dans un établissement de soins infirmiers ou en soins palliatifs. Cet attribut est essentiel au suivi de la planification des sorties et des tendances de réadmission. Il renseigne sur la complexité de la planification de la sortie et aide à évaluer l’efficacité des transitions de soins. Pourquoi est-ce important ? Contexte essentiel pour planifier les sorties et évaluer le risque de réadmission. Où trouver ces données Champs de consultation d’athenahealth ou dossiers de sortie de l’hôpital. Exemples DomicileÉtablissement de soins infirmiersTransfert vers un hôpital de court séjourDécès
	Heure de fin de l’événement EventEndTime	Heure à laquelle l’activité concernée a été terminée.
Description Enregistre l’heure de fin d’une activité et permet de calculer sa durée de traitement, distincte du temps d’attente qui la précède. Cet attribut sert à analyser l’efficacité des ressources et à repérer les tâches dont l’exécution manuelle prend plus de temps que prévu. Pourquoi est-ce important ? Permet de calculer la durée de traitement active et de la distinguer du temps d’attente passif. Où trouver ces données Heure de sortie, heure de vérification des résultats ou horodatages de fin spécifiques dans athenahealth. Exemples 2023-10-12T09:00:00Z2023-10-12T10:45:00Z
	Identifiant du patient PatientId	Identifiant unique du patient, anonymisé ou haché.
Description Identifie de manière unique le patient concerné par le parcours. Contrairement à l’identifiant du cas, un même patient peut connaître plusieurs épisodes au fil du temps. Cet attribut permet de relier les visites répétées et d’analyser les taux de réadmission. Il est essentiel à l’indicateur « Pourcentage de réadmissions non programmées ». Pourquoi est-ce important ? Nécessaire pour suivre les réadmissions et l’historique du patient d’un épisode à l’autre. Où trouver ces données Champ « patientid » d’athenahealth. Exemples PAT-100234PAT-559201PAT-992210
	Nom du professionnel de santé ProviderName	Nom du professionnel de santé qui a effectué l’activité.
Description Identifie le médecin, l’infirmier ou le technicien responsable de l’événement. Cet attribut est essentiel à l’analyse de l’utilisation des ressources. Il permet de comparer les indicateurs de performance, comme le débit et le temps de cycle, entre les membres du personnel afin de repérer les besoins de formation ou les déséquilibres de charge de travail. Pourquoi est-ce important ? Indispensable pour calculer le taux d’utilisation des ressources et analyser les transferts de responsabilité. Où trouver ces données Valeur « providerid » d’athenahealth associée au nom du professionnel dans le répertoire. Exemples Dr SmithInfirmière JonesTechnicien Adams
	Nom du service DepartmentName	Service de l’hôpital ou de la clinique où l’activité a eu lieu.
Description Segmente les données du processus par unité fonctionnelle, par exemple les urgences, la cardiologie ou la radiologie. Cet attribut est indispensable au Dashboard « Débit et transferts entre services ». Son analyse met en évidence les goulots d’étranglement dans certains services et aide à optimiser le parcours du patient entre les services. Pourquoi est-ce important ? Essentiel pour repérer les goulots d’étranglement organisationnels et les transferts de responsabilité inefficaces. Où trouver ces données Valeur « departmentid » d’athenahealth associée au nom du service. Exemples Service des urgencesMédecine interneRadiologie
	Réadmission IsReadmission	Indique si cet épisode correspond à un retour non programmé.
Description Indicateur booléen qui précise 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. Il contribue directement au calcul de l’indicateur « Pourcentage de réadmissions non programmées ». En filtrant sur cet attribut, les analystes peuvent examiner les causes profondes des réadmissions et repérer les tendances dans les parcours de soins initiaux. Pourquoi est-ce important ? Contribue directement au calcul du taux de réadmission. Où trouver ces données Calculé pendant l’ETL en comparant la date d’admission à la date de sortie précédente. Exemples truefalse
	Tranche d’âge du patient PatientAgeGroup	Catégorie d’âge du patient, par exemple 18-25 ans ou 65 ans et plus.
Description Répartit les patients en cohortes démographiques. Cet attribut est nécessaire au Dashboard « Comparaison des parcours par tranche d’âge et diagnostic ». Il aide à déterminer si les inefficacités du processus ou les résultats touchent davantage certaines tranches d’âge, comme les personnes âgées ou les enfants. Pourquoi est-ce important ? Segment démographique standard pour l’analyse des processus de soins. Où trouver ces données Calculé à partir de la date de naissance du patient et de l’heure de début. Exemples 18-2930-4965+
	Type de consultation EncounterType	Catégorie de la visite, par exemple consultation au cabinet, télésanté ou urgence.
Description Définit la modalité ou le cadre des soins prodigués. Dans les modèles de données génériques, cet attribut correspond au « type de cas ». Les différents types de consultation suivent des parcours attendus et des exigences de facturation qui leur sont propres. Il est essentiel de filtrer selon cet attribut pour comparer des cas similaires dans l’analyse du temps de cycle. Pourquoi est-ce important ? Permet de distinguer les variantes du processus, comme la télésanté et les consultations en personne. Où trouver ces données Champ « encountertype » d’athenahealth. Exemples Consultation au cabinetTélésantéUrgenceChirurgie
	Montant total facturé TotalChargeAmount	Montant facturé pour l’activité ou l’épisode.
Description Valeur financière associée à l’activité ou montant total de la demande de remboursement. Cet attribut permet d’effectuer un Process Mining axé sur les coûts et d’analyser l’impact financier. Il sert à repérer les variantes de parcours de soins coûteuses et à mettre en relation l’efficacité du processus et les résultats financiers. Pourquoi est-ce important ? Ajoute une dimension financière à l’analyse du processus. Où trouver ces données Valeur « amount » ou « totalcharge » d’athenahealth dans les tables de demandes de remboursement ou de frais. Exemples 150.002500.5045.00
	Reprise IsRework	Indique si cette activité est répétée.
Description Indicateur booléen qui prend la valeur vraie si l’activité s’est produite plusieurs fois dans le même cas. Il contribue au Dashboard « Fréquence des activités et boucles de reprise ». Il permet d’isoler rapidement les cas comportant des reprises et de calculer l’indicateur « Fréquence des activités reprises ». Pourquoi est-ce important ? Met en évidence les inefficacités du processus et les étapes redondantes. Où trouver ces données Calculé pendant l’ETL à partir du nombre d’occurrences de chaque activité par identifiant de cas. Exemples truefalse
	Statut de la demande de remboursement ClaimStatus	Statut de la demande de remboursement liée aux soins.
Description Indique l’état de la demande de remboursement, par exemple soumise, refusée ou payée. Cet attribut est pertinent pour l’activité « Demande de remboursement soumise » et le débit financier. Il aide à déterminer si des problèmes de documentation clinique entraînent des retards dans le traitement financier. Pourquoi est-ce important ? Relie l’efficacité clinique à la performance du cycle de revenus. Où trouver ces données Champ « claimstatus » d’athenahealth. Exemples FACTURÉEEN ATTENTETRANSMISE
	Statut du résultat diagnostique DiagnosticResultStatus	Résultat d’une demande d’examen diagnostique, par exemple positif ou normal.
Description Consigne le résultat général d’un examen. Il apporte un contexte utile pour analyser le délai des examens diagnostiques et les décisions thérapeutiques qui suivent. Cet attribut permet de vérifier si les résultats anormaux entraînent des actions ultérieures plus rapides que les résultats normaux. Pourquoi est-ce important ? Relie le flux du processus aux résultats cliniques. Où trouver ces données Champs d’observation des résultats d’analyse d’athenahealth. Exemples NormalAnormalCritique
	Type de demande OrderType	Catégorie de la demande, par exemple analyse, imagerie ou ordonnance.
Description Classe les demandes cliniques effectuées pendant l’épisode. Cet attribut est essentiel au Dashboard « Délai des examens diagnostiques ». Il permet aux analystes de mesurer séparément les délais des analyses et de l’imagerie, qui sont souvent soumis à des accords de niveau de service et à des goulots d’étranglement différents. Pourquoi est-ce important ? Segmente le processus diagnostique pour analyser les délais correspondants. Où trouver ces données Valeur « ordertype » ou « class » dans l’API des demandes d’athenahealth. Exemples AnalyseImagerieOrdonnanceProcédure

Obligatoire Recommandé Facultatif

Activités du parcours patient

Voici les étapes et les jalons du processus à enregistrer dans votre journal d’événements pour reconstituer et optimiser le parcours patient avec précision.

7 Recommandé 8 Facultatif

	Activité	Description
	Diagnostic confirmé	Un clinicien attribue ou confirme officiellement un diagnostic pour l’état du patient lors de la consultation en cours. L’événement peut être déduit de l’horodatage de création ou de dernière mise à jour du code de diagnostic principal, comme le code CIM-10, associé à la consultation.
Pourquoi est-ce important ? Cette étape déterminante oriente la suite du parcours de soins. L’analyse des variations d’activité après ce point aide à comprendre et à harmoniser les protocoles de prise en charge. Où trouver ces données L’événement est déduit de la liste des problèmes du patient ou des données de diagnostic de la consultation. Une modification ou la validation du code de diagnostic, avec son horodatage, signale cet événement. Données à recueillir Repérez l’horodatage auquel le diagnostic principal de la consultation est ajouté ou mis à jour. Type d’événement inferred
	Évaluation initiale terminée	Indique la fin de la première évaluation clinique, par exemple le triage ou l’évaluation infirmière, au cours de laquelle les signes vitaux et les principaux motifs de consultation sont consignés. Cet événement est souvent déduit de l’horodatage de la première note clinique signée ou du formulaire d’évaluation rempli pour la consultation.
Pourquoi est-ce important ? Cette étape marque le début des soins cliniques. Le délai entre l’enregistrement à l’arrivée et cette activité est un indicateur important du temps d’attente initial et de la réactivité des équipes. Où trouver ces données L’événement est déduit de l’horodatage de création ou de signature de documents cliniques ou de feuilles de suivi dans athenaClinicals. Il faut identifier les types de documents utilisés pour le triage ou l’accueil. Données à recueillir Repérez le premier horodatage d’une note clinique, d’une feuille de suivi des signes vitaux ou d’un formulaire d’accueil associé à la consultation. Type d’événement inferred
	Ordre de sortie rédigé	Un médecin ou un professionnel de santé habilité rédige un ordre officiel de sortie du patient. Cet événement explicite et horodaté est créé dans le module CPOE du dossier médical électronique.
Pourquoi est-ce important ? Cette activité déclenche le processus de sortie. Le délai entre la rédaction de l’ordre et la sortie effective est un indicateur clé du délai de planification de la sortie. Où trouver ces données L’événement figure dans la table des prescriptions. Il est identifié par un type d’ordre « Discharge » et son horodatage de création. Données à recueillir Un nouvel enregistrement de type « Discharge » est créé dans la table des prescriptions. Type d’événement explicit
	Patient enregistré à son arrivée	Cette activité indique l’arrivée du patient et son enregistrement officiel pour le rendez-vous ou la visite prévue. Elle est généralement enregistrée comme un changement de statut explicite du rendez-vous dans athenaClinicals ou athenaCommunicator.
Pourquoi est-ce important ? Il s’agit du début officiel du parcours du patient sur place. Ce point de départ permet de mesurer les temps d’attente et le temps de cycle global d’une consultation clinique. Où trouver ces données L’événement est enregistré comme une mise à jour du statut dans les tables des rendez-vous ou des consultations. Recherchez le statut « Checked-In » et l’horodatage correspondant. Données à recueillir Un changement de statut de l’objet rendez-vous ou consultation est enregistré avec un horodatage. Type d’événement explicit
	Patient sorti	La sortie officielle du patient marque la fin de son séjour dans l’établissement. Il s’agit du dernier événement ADT d’une hospitalisation, enregistré avec un horodatage précis.
Pourquoi est-ce important ? Cet événement marque la fin du parcours principal du patient. Il sert de point final pour mesurer le temps de cycle global du parcours patient et est indispensable à l’analyse des réadmissions. Où trouver ces données Cet événement explicite figure dans le système ADT ou dans la table des consultations du patient. Il indique le statut final « Discharged » de la consultation et comporte un horodatage. Données à recueillir Le statut de la consultation du patient passe à « Discharged » et un événement ADT est enregistré. Type d’événement explicit
	Procédure réalisée	Une procédure clinique, comme une intervention chirurgicale ou une thérapie spécialisée, est réalisée sur le patient. Cet événement explicite est consigné dans la documentation clinique, souvent avec les heures de début et de fin dans une note de procédure.
Pourquoi est-ce important ? Les procédures constituent des étapes importantes du traitement. L’analyse des activités qui les précèdent et leur succèdent aide à optimiser les flux de travail préopératoires et postopératoires. Où trouver ces données L’événement figure dans les notes de procédure ou les feuilles de suivi clinique d’athenaClinicals. Son horodatage est établi à partir de l’heure de début ou de fin consignée. Données à recueillir Une note ou un journal de procédure est créé et indique l’horodatage de sa réalisation. Type d’événement explicit
	Résultats d’examen reçus	Les résultats d’un examen diagnostique sont finalisés et mis à la disposition du patient dans son dossier. Ils sont généralement enregistrés lorsqu’un système de laboratoire ou d’imagerie les transmet à athenahealth, ce qui crée une entrée horodatée.
Pourquoi est-ce important ? La réception des résultats déclenche des décisions cliniques ultérieures, comme le diagnostic et la planification du traitement. Cet événement marque la fin du délai de traitement des examens diagnostiques. Où trouver ces données L’événement figure dans la table des résultats ou des examens diagnostiques et est associé à la prescription d’origine. Il est horodaté au moment où le résultat est versé au dossier du patient ou reçu dans celui-ci. Données à recueillir Un nouvel enregistrement de résultat est créé avec un horodatage, souvent par l’intermédiaire d’une interface avec un LIS ou un RIS. Type d’événement explicit
	Demande de remboursement soumise	Une demande de remboursement correspondant aux services fournis pendant la consultation du patient est générée et transmise à l’organisme payeur. Cet événement explicite figure dans le module de gestion du cycle de revenus athenaCollector.
Pourquoi est-ce important ? Bien qu’il s’agisse d’une étape administrative, cette activité est essentielle pour analyser le cycle de revenus, qui se déroule en parallèle du parcours clinique. Elle permet de repérer les délais entre les soins et la facturation. Où trouver ces données Présent dans les tables de demandes de remboursement ou de facturation. L’événement est identifié par l’horodatage de création ou de soumission d’une demande. Données à recueillir Un enregistrement de demande de remboursement est créé et son statut passe à « Soumise », avec un horodatage. Type d’événement explicit
	Échantillon prélevé	Cet événement correspond au prélèvement d’un échantillon biologique, comme du sang ou de l’urine, pour une analyse de laboratoire. Il est généralement enregistré explicitement dans le module de laboratoire ou sous la forme d’une mise à jour du statut de la prescription.
Pourquoi est-ce important ? Cette étape importante du processus diagnostique permet de repérer les goulots d’étranglement dans les flux de travail du laboratoire en analysant les délais entre la prescription, le prélèvement et la réception des résultats. Où trouver ces données L’événement peut apparaître comme un changement de statut de la prescription de laboratoire ou comme un événement distinct dans un système d’information de laboratoire connecté à athenahealth. Recherchez le statut « Collected » et son horodatage. Données à recueillir L’événement est enregistré comme une mise à jour du statut de la prescription de laboratoire ou dans un module dédié au suivi des échantillons. Type d’événement explicit
	Examen diagnostique prescrit	Un professionnel de santé prescrit un examen diagnostique, par exemple une analyse de laboratoire, un examen d’imagerie ou une autre procédure. Cet événement explicite, horodaté, est créé à l’aide de la fonction CPOE (Computerized Provider Order Entry) d’athenaClinicals.
Pourquoi est-ce important ? Cette décision importante déclenche un sous-processus diagnostique. Le suivi de cette activité est essentiel pour mesurer l’indicateur « Diagnostic Test Lead Time », du moment de la prescription à la réception du résultat. Où trouver ces données L’événement figure dans la table des prescriptions. Chaque prescription comporte un identifiant de patient, un nom, un statut et un horodatage de création. Données à recueillir Un nouvel enregistrement horodaté est créé dans la table des prescriptions du système. Type d’événement explicit
	Médicament administré	Un membre du personnel clinique administre physiquement un médicament au patient. Chaque dose est enregistrée explicitement dans le module Medication Administration Record (MAR) d’athenaClinicals, avec un horodatage précis.
Pourquoi est-ce important ? Cette activité correspond à une intervention thérapeutique directe. L’analyse de son horaire permet de mesurer le délai avant le premier traitement et de vérifier le respect du calendrier d’administration des médicaments. Où trouver ces données L’événement figure dans les tables de données MAR. Chaque administration comporte un identifiant de patient, un identifiant de médicament, une dose et un horodatage. Données à recueillir Un enregistrement horodaté est créé dans le MAR chaque fois que l’administration d’un médicament est consignée. Type d’événement explicit
	Patient transféré	Le patient est transféré d’une unité de soins ou d’un service à un autre, par exemple des urgences vers un service d’hospitalisation. Ce transfert est enregistré explicitement sous la forme d’un événement ADT (Admission, Discharge, Transfer) dans le dossier médical électronique.
Pourquoi est-ce important ? Cette activité est importante pour analyser les relais entre services et le parcours des patients dans un établissement. Elle aide à repérer les goulots d’étranglement dans le délai de transfert des patients et les problèmes d’affectation des ressources. Où trouver ces données L’événement figure dans le journal d’événements ADT ou dans les tables de suivi des patients. Chaque transfert indique le patient, le lieu de départ, le lieu d’arrivée et un horodatage. Données à recueillir Un message ADT ou une entrée dans le journal d’événements est généré avec un horodatage au moment du transfert du patient. Type d’événement explicit
	Plan de traitement établi	Un clinicien crée et consigne officiellement le plan de traitement du patient. L’événement peut correspondre à la création ou à la signature d’un document « Plan of Care » ou d’un ensemble de prescriptions de traitement associées.
Pourquoi est-ce important ? Cette activité formalise le parcours de soins prévu. Elle constitue un repère important pour mesurer le respect des protocoles standard et analyser les variations de prise en charge. Où trouver ces données L’événement figure probablement dans les tables des documents cliniques ou des prescriptions. Il correspond à l’horodatage d’une note de plan de soins signée ou à la soumission d’un ensemble coordonné de prescriptions de traitement. Données à recueillir L’événement correspond à l’horodatage de création ou de validation d’un document de plan de traitement ou d’un ensemble de prescriptions. Type d’événement explicit
	Rendez-vous de suivi planifié	Un rendez-vous de suivi est planifié après le traitement principal ou la sortie du patient. Cet événement est enregistré explicitement lorsqu’un nouveau rendez-vous est créé dans le module de planification athenaCommunicator.
Pourquoi est-ce important ? Cette activité permet d’évaluer la coordination des soins après la sortie et ses effets sur des résultats comme le taux de réadmission. Elle témoigne de la continuité des soins. Où trouver ces données L’événement figure dans la table des rendez-vous. Il est identifié par l’horodatage de création d’un rendez-vous prévu après la date de sortie. Données à recueillir Un nouveau rendez-vous est créé dans le système de planification. Type d’événement explicit
	Rendez-vous planifié	Cet événement correspond à la prise de rendez-vous d’un patient. Il est enregistré explicitement lorsqu’un utilisateur crée et confirme un nouveau rendez-vous dans le module de planification athenaCommunicator d’athenahealth.
Pourquoi est-ce important ? Cette activité marque le début de nombreux parcours patients. L’analyse du délai entre la prise de rendez-vous et l’enregistrement à l’arrivée permet d’évaluer l’accès aux soins et l’efficacité de la préparation de la visite. Où trouver ces données Cet événement explicite figure dans les tables des rendez-vous ou de planification. Il est généralement associé à un horodatage de création et à l’identifiant du patient. Données à recueillir L’événement est enregistré à la création d’un rendez-vous dans le module de planification. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données d’athenahealth

Étapes

Connectez-vous au portail athenaNet à l’aide de vos identifiants sécurisés.
Dans le menu principal, ouvrez le module Reports, généralement accessible sous « Reports » > « Report Builder » ou « Custom Reports ».
Cliquez sur « Create New Report », puis sélectionnez « Encounters » ou « Patient Visit » comme catégorie principale du rapport. Les données détaillées porteront ainsi sur un épisode de soins précis.
Dans la zone de sélection « Columns » ou « Fields », recherchez et ajoutez Patient Identifier (Patient ID) et Encounter Identifier (Encounter ID) pour les utiliser comme identifiant de cas.
Ajoutez les colonnes démographiques et contextuelles nécessaires aux attributs, par exemple Department, Provider Name, Patient Age et Primary Diagnosis Code.
Ajoutez les colonnes d’horodatage correspondant aux activités. Vous devrez peut-être consulter différents groupes de champs, par exemple « Scheduling » pour Appointment Scheduled, « Check-in » pour Check-in Time et « Billing » pour Claim Submitted. Lorsque ces formats sont proposés, sélectionnez « Date and Time » plutôt que « Date » seul.
Appliquez des filtres à la configuration du rapport. Définissez la période souhaitée pour « Encounter Date » (par exemple, les six derniers mois) et excluez les rendez-vous « Cancelled » ou « No Show » afin de vous concentrer sur les parcours achevés.
Cliquez sur « Run Report » pour prévisualiser les données. Vérifiez que les colonnes contiennent des données et ne sont pas entièrement nulles.
Sélectionnez « Export », puis choisissez le format « CSV » (Comma Separated Values). Évitez les options de mise en forme Excel/XLSX, qui compliquent le traitement.
Enregistrez le fichier localement sous le nom « athena_raw_export.csv ».
Le rapport exporte une ligne par rencontre et plusieurs colonnes de dates (format large). Vous devez donc le restructurer en journal d’événements (format long). Utilisez le script Python fourni dans la section Query pour effectuer cette transformation.
Exécutez le script pour générer le fichier final « process_mining_event_log.csv », puis importez-le dans ProcessMind.

Configuration

Catégorie de rapport : Choisissez « Encounter Activity » ou « Clinicals » comme catégorie de base pour recueillir la plupart des étapes du flux de travail clinique.
Période : Limitez l’extraction initiale à 3 à 6 mois afin d’éviter les délais d’attente ou les limites de lignes des rapports, généralement fixées à environ 50 000 lignes dans les vues standard.
Sélection des colonnes : Veillez à sélectionner explicitement les champs d’horodatage. Préférez « Check-in Date/Time », qui indique une date et une heure précises, aux champs calculés comme « Days since check-in ».
Gestion des valeurs nulles : Configurez le rapport pour afficher des cellules vides lorsque des données sont manquantes, plutôt qu’un texte personnalisé comme « N/A », afin de simplifier le traitement par script.
Filtrage par service : Si l’organisation est de grande taille, filtrez par lieu de soins ou service, par exemple « Cardiology » ou « Orthopedics », pour limiter le périmètre des données.
Autorisations : L’utilisateur doit disposer des autorisations « Report Creator » ou « Clinical Reporting » dans athenaNet pour accéder à Custom Report Builder.

a Exemple de requête python

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

class=class="hl-string">"hl-comment"># Configuration: Input and Output filenames
INPUT_FILE = class="hl-string">'athena_raw_export.csv'
OUTPUT_FILE = class="hl-string">'patient_journey_event_log.csv'

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

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

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

class=class="hl-string">"hl-comment"># Initialize list to hold event rows
event_log_data = []

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

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

class=class="hl-string">"hl-comment"># Create DataFrame from the list of events
event_log_df = pd.DataFrame(event_log_data)

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

class=class="hl-string">"hl-comment"># Remove rows where timestamp parsing failed
event_log_df = event_log_df.dropna(subset=[class="hl-string">'EventTimestamp'])

class=class="hl-string">"hl-comment"># Sort by Episode and Time
event_log_df = event_log_df.sort_values(by=[class="hl-string">'PatientEpisodeId', class="hl-string">'EventTimestamp'])

class=class="hl-string">"hl-comment"># Output to CSV
event_log_df.to_csv(OUTPUT_FILE, index=False)

print(fclass="hl-string">"Transformation complete. Processed {len(df)} encounters into {len(event_log_df)} events.")
print(fclass="hl-string">"File saved to: {OUTPUT_FILE}")

Étapes

Enregistrer une application API : Connectez-vous au portail développeur d’athenahealth et enregistrez une nouvelle application pour obtenir votre Client ID et votre Client Secret. Vérifiez que l’application dispose des autorisations nécessaires pour Appointments, Clinicals (Charts), Orders et Billing (Claims).
Configurer l’environnement Python : Installez les bibliothèques Python requises (requests, pandas) dans votre environnement d’exécution à l’aide de la commande pip install requests pandas.
S’authentifier : Mettez en œuvre le flux OAuth 2.0 Client Credentials pour obtenir un jeton d’accès. Ce jeton doit figurer dans l’en-tête Authorization (Bearer token) de tous les appels API suivants.
Définir le périmètre : Indiquez le Practice ID et la période d’extraction. Les API d’athenahealth sont propres à chaque cabinet. Si vous en gérez plusieurs, vous devez donc parcourir leurs identifiants.
Extraire les rendez-vous : Interrogez le point de terminaison /appointments/booked ou /appointments/changed pour récupérer les rencontres de base. Associez l’ID du rendez-vous à PatientEpisodeId. Utilisez la date de création pour extraire « Appointment Scheduled » et l’heure d’arrivée pour « Patient Checked In ».
Parcourir les rencontres pour extraire les événements cliniques : Pour chaque ID de rendez-vous (rencontre), interrogez les sous-points de terminaison cliniques. Appelez /chart/{encounterId}/vitals pour « Initial Assessment Completed ». Appelez /chart/{encounterId}/orders pour « Diagnostic Test Ordered », « Specimen Collected » (selon le statut) et « Discharge Order Written ».
Récupérer les résultats et les diagnostics : Interrogez /chart/{encounterId}/analyteresults ou /chart/{encounterId}/labresults pour « Test Results Received ». Interrogez /chart/{encounterId}/diagnoses pour « Diagnosis Confirmed ».
Extraire les traitements et les actes : Interrogez /chart/{encounterId}/plan pour « Treatment Plan Developed ». Interrogez /chart/{encounterId}/procedures pour « Procedure Performed ». Interrogez /chart/{encounterId}/medications/admin pour « Medication Administered ».
Repérer les événements ADT et les demandes de remboursement : Utilisez l’historique des statuts de rendez-vous ou les points de terminaison hospitaliers dédiés, s’ils sont disponibles, pour enregistrer « Patient Transferred » et « Patient Discharged ». Interrogez /claims pour les demandes liées au rendez-vous et extraire « Claim Submitted ».
Associer les rendez-vous de suivi : Repérez « Follow-Up Appointment Scheduled » en recherchant les rendez-vous ultérieurs créés pour le même patient pendant la période de la rencontre.
Transformer et aplatir les données : Analysez les réponses JSON imbriquées pour obtenir une liste plate de dictionnaires d’événements. Convertissez tous les horodatages au format ISO 8601. Associez les champs à ActivityName, PatientEpisodeId et EventTimestamp.
Exporter les données : Chargez la liste de dictionnaires dans un DataFrame pandas, effectuez le nettoyage final (notamment la gestion des valeurs nulles), puis exportez le résultat dans un fichier CSV prêt à être importé dans ProcessMind.

Configuration

Identifiants API : Un Client ID et un Client Secret valides, obtenus sur le portail développeur d’athenahealth, avec un accès à l’environnement de production, sont requis.
Practice ID : Identifiant numérique unique du cabinet médical. Si vous extrayez les données d’un réseau, le script doit être exécuté pour chaque cabinet.
Période : Une période d’extraction de 3 à 6 mois est recommandée, compte tenu du volume de données cliniques détaillées.
Limitation du débit : L’API athenaOne applique des limites strictes, par exemple 5 appels par seconde. Le script inclut une fonction de pause, mais les extractions à l’échelle de l’entreprise doivent prévoir un délai exponentiel entre les tentatives.
Autorisations : Vérifiez que le jeton dispose des autorisations athena/service/Athenanet.MDP.* ou des autorisations spécifiques aux rendez-vous, aux dossiers et aux données financières.
Pagination : La plupart des points de terminaison renvoient un nombre limité d’enregistrements, 1 000 par défaut. Le script doit gérer les paramètres next ou offset.
Filtrage par service : Pour analyser des parcours précis, par exemple les urgences ou les soins ambulatoires, filtrez par ID de service lors de l’extraction 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()

Prêt à commencer ?

Lancez-vous dans l’amélioration des soins aux patients. Ce modèle constitue une première étape pour obtenir des analyses utiles et améliorer les résultats de santé.

Retour au guide d’amélioration Télécharger le modèle

Optimisez dès maintenant le parcours patient et éliminez les goulots d’étranglement

Repérez les inefficacités dans athenahealth et réduisez de 30 % le temps de cycle du parcours patient.

Démarrez l’essai gratuit

Aucune carte bancaire n’est requise. Commencez dès aujourd’hui à optimiser vos processus.

Votre modèle de données pour le parcours patient

Votre modèle de données pour le parcours patient

Attributs du parcours patient

Activités du parcours patient

Guides d’extraction

Export CSV personnalisé avec athenaNet Report Builder

Étapes

Configuration

a Exemple de requête python

Extraction des événements de l’API athenaOne avec Python

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant le parcours patient et éliminez les goulots d’étranglement

Votre modèle de données pour le parcours patient

Votre modèle de données pour le parcours patient

Attributs du parcours patient

Activités du parcours patient

Guides d’extraction

Export CSV personnalisé avec athenaNet Report Builder

Étapes

Configuration

a Exemple de requête python

Extraction des événements de l’API athenaOne avec Python

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant le parcours patient et éliminez les goulots d’étranglement

Nous respectons votre vie privée

Prêt à commencer ?