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

Votre `template` de données de Parcours Patient

athenahealth

Attributs du Parcours Patient (20) Activités du Parcours Patient (15) Guides d'extraction (2)

Votre `template` de données de Parcours Patient

Ce `template` fournit un guide complet 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

Nouveau dans 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 `event log`, essentiels pour une analyse complète et une compréhension de vos parcours patients.

5 Obligatoire 10 Recommandé 5 Facultatif

	Nom	Description
	Dernière mise à jour des données LastDataUpdate	L'horodatage de la dernière extraction ou actualisation des données.
Description Indique la fraîcheur 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 `data pipelines` et garantir que les `dashboards` reflètent l'état le plus actuel du processus. Pourquoi c'est important Crucial pour la gouvernance des données et la confiance des utilisateurs dans la fraîcheur du tableau de bord. Où obtenir 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.
Description 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 de bout en bout. Il garantit que plusieurs visites du même patient pour différentes conditions sont traitées comme des instances de processus distinctes. Pourquoi c'est important Essentiel pour définir la portée d'une seule instance de processus au sein de l'analyse. Où obtenir 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
	Nom de l'activité ActivityName	Le nom de l'événement ou de la tâche effectuée dans le parcours patient.
Description 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 `process flow` et identifier la séquence des opérations. La standardisation de ces noms est essentielle pour une carte de processus claire et lisible. Pourquoi c'est important Définit les étapes de la cartographie des processus et est obligatoire pour toute activité de Process Mining. Où obtenir 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.
Description 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 c'est important Fournit la `data lineage` et le contexte dans les configurations de Process Mining multi-systèmes. Où obtenir Littéral codé en dur ou ID de configuration du système. Exemples athenahealthAthenaOneAthenaPractice
	Timestamp de l'événement EventTimestamp	La date et l'heure spécifiques auxquelles l'activité s'est produite.
Description 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. Crucial pour l'analyse basée sur le temps, y compris les temps de cycle, les temps d'attente et l'analyse du `throughput`. Une haute précision est préférée pour résoudre l'ordre des événements se produisant le même jour. Pourquoi c'est important Requis pour ordonner les événements et calculer tous les KPI basés sur le temps. Où obtenir Champs `timestamp` 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
	Code de diagnostic principal PrimaryDiagnosisCode	Le code CIM-10 principal associé à l'épisode.
Description 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 c'est important Permet la comparaison de cas 'similaires'; les temps de cycle varient énormément selon le diagnostic. Où obtenir Champs de diagnostic de l'épisode de soins ou de la réclamation (CIM-10). Exemples J18.9I10E11.9
	Est une réadmission IsReadmission	Indicateur signalant si cet épisode représente un retour non planifié.
Description 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 soutient directement l'ICP '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 c'est important Soutient directement l'ICP de taux de réadmission. Où obtenir Calculé pendant l'ETL en comparant la date d'admission à la date de sortie précédente. Exemples truefaux
	Groupe d'âge du patient PatientAgeGroup	Regroupement catégoriel de l'âge du patient (par exemple, 18-25, 65+).
Description Segmente les patients en cohortes démographiques. Ceci est directement requis pour le `dashboard` '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 c'est important Segment démographique standard pour l'analyse des processus de soins de santé. Où obtenir 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é complétée.
Description 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 c'est important Permet le calcul du temps de traitement actif par rapport au temps d'attente passif. Où obtenir 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é).
Description 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 critique pour le KPI 'Pourcentage de réadmissions non planifiées'. Pourquoi c'est important Nécessaire pour suivre les réadmissions et l'historique du patient à travers les épisodes. Où obtenir Champ 'patientid' d'athenahealth. Exemples PAT-100234PAT-559201PAT-992210
	Motif de sortie DischargeDisposition	La destination ou le statut du patient à sa sortie.
Description Indique où le patient s'est rendu après l'épisode, par exemple 'À domicile', 'Établissement de soins infirmiers qualifiés' ou 'Hospice'. Ceci est vital pour 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 c'est important Contexte critique pour la planification des sorties et le risque de réadmission. Où obtenir Champs d'épisode de soins athenahealth ou dossiers de sortie d'hôpital. Exemples AccueilÉtablissement de soins infirmiers qualifiésTransféré à l'hôpital de court séjourExpiré
	Nom du département DepartmentName	Le département hospitalier ou clinique où l'activité a eu lieu.
Description Segmente les données de processus par unité fonctionnelle, telles que les Urgences, la Cardiologie ou la Radiologie. Ceci est essentiel pour le `dashboard` 'Débit départemental et passations'. L'analyse utilisant cet attribut met en évidence les goulots d'étranglement dans des zones spécifiques et aide à optimiser le flux de patients inter-départemental. Pourquoi c'est important Crucial pour identifier les goulots d'étranglement organisationnels et les inefficacités de transfert. Où obtenir Champ 'departmentid' d'athenahealth résolu en nom de département. Exemples Service des urgencesMédecine interneRadiologie
	Nom du prestataire ProviderName	Le nom du professionnel de la santé effectuant l'activité.
Description Identifie le médecin, l'infirmière ou le technicien spécifique responsable de l'événement. Cet attribut est essentiel à 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 c'est important Clé pour le 'Taux d'utilisation des ressources' et l'analyse des passations. Où obtenir Champ 'providerid' d'athenahealth résolu en nom de prestataire. Exemples Dr. SmithInfirmière JonesTech Adams
	Temps de traitement ProcessingTime	La durée consacrée activement à l'activité.
Description Représente la différence de temps entre le début et la fin d'une tâche spécifique (par exemple, le temps nécessaire pour effectuer un scan). Ceci correspond au 'ProcessingTime' dans le modèle générique. Utilisé pour calculer l'utilisation des ressources et identifier les écarts d'efficacité entre les tâches manuelles et automatisées. Pourquoi c'est important Différencie le travail actif du temps d'attente dans le cycle total. Où obtenir Calculé : EventEndTime - EventTimestamp. Exemples 15min1h 30min45s
	Type d'épisode de soins EncounterType	La classification de la visite (par exemple, Visite au cabinet, Télésanté, Urgence).
Description 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 essentiel pour éviter de comparer des éléments incomparables dans l'analyse des temps de cycle. Pourquoi c'est important Distingue les différentes variantes de processus, telles que la télésanté ou les consultations en personne. Où obtenir Champ 'encountertype' d'athenahealth. Exemples Visite au cabinetTélésantéUrgenceChirurgie
	Est un retravail IsRework	Indicateur signalant si cette activité est une répétition.
Description 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 retravail'. Il permet l'isolement immédiat des cas contenant du retravail, facilitant le calcul de l'ICP 'Fréquence des activités de retravail'. Pourquoi c'est important Identifie les inefficacités du processus et les étapes redondantes. Où obtenir 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.
Description 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 c'est important Ajoute une dimension financière à l'analyse des processus. Où obtenir 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).
Description 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 c'est important Relie le flux de processus aux résultats cliniques. Où obtenir 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.
Description 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 `throughput` financier. Aide à identifier si des problèmes de documentation clinique entraînent des retards financiers en aval. Pourquoi c'est important Lie l'efficacité clinique à la performance du cycle de revenus. Où obtenir Champ 'claimstatus' d'athenahealth. Exemples FACTURÉEN ATTENTEDROP
	Type de commande OrderType	Catégorie de la commande (par exemple, Laboratoire, Imagerie, Prescription).
Description Classe les commandes cliniques passées pendant l'épisode. Ceci est crucial 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 goulots d'étranglement différents. Pourquoi c'est important Segmente le processus diagnostique pour une analyse spécifique du délai d'exécution. Où obtenir 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 `event log` pour une découverte et une optimisation précises de l'expérience patient.

7 Recommandé 8 Facultatif

	Activité	Description
	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 c'est 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. Où obtenir 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 `timestamp` 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 complété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 `timestamp` de la première note clinique signée ou d'un formulaire d'évaluation complété pour la rencontre.
Pourquoi c'est 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. Où obtenir Déduit du `timestamp` 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 `timestamp` 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 c'est 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'. Où obtenir Situé dans la table des commandes. L'événement est identifié par un type de commande de 'Sortie' spécifique et son `timestamp` 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 c'est important C'est le début définitif du parcours sur site du patient. Il sert de point de départ crucial pour mesurer les temps d'attente et le temps de cycle global d'une rencontre clinique. Où obtenir Enregistré comme une mise à jour de statut dans les tables de rendez-vous ou de rencontres. Recherchez un statut 'Checked-In' (enregistré) et son `timestamp` 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 `timestamp` précis.
Pourquoi c'est 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 essentiel pour l'analyse des réadmissions. Où obtenir 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 `timestamp`. 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 réalisé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 documentation clinique, souvent avec des heures de début et de fin spécifiques enregistrées dans une note de procédure.
Pourquoi c'est 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. Où obtenir 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 c'est 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. Où obtenir Situé dans la table des résultats ou des diagnostics, lié à la commande originale. L'événement est marqué par le `timestamp` 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 c'est 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. Où obtenir 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 c'est important Cette activité est cruciale pour analyser les passations départementales et le flux patient au sein d'une installation. Elle aide à identifier les goulots d'étranglement dans le 'Temps de passation patient' et l'allocation des ressources. Où obtenir Enregistré dans le `event log` 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 `timestamp`. 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 c'est 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. Où obtenir Probablement trouvé dans les documents cliniques ou les tables d'ordres. Cet événement correspond au `timestamp` 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 c'est important Cette activité est essentielle 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. Où obtenir Enregistré dans la table des rendez-vous. L'événement est identifié par un `timestamp` 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 c'est 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. Où obtenir 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 `timestamp` 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 c'est important Bien qu'il s'agisse d'une étape administrative, cette activité est cruciale 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. Où obtenir 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 c'est 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 goulots d'étranglement significatifs dans les `workflows` de laboratoire. Où obtenir 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 `timestamp`. Capture Enregistré 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 c'est important C'est un point de décision critique qui initie un sous-processus diagnostique. Le suivi de cette activité est essentiel pour analyser le KPI 'Délai d'exécution du test diagnostique' de la commande au résultat. Où obtenir 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 EventTimestamp.
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 `template` de données de Parcours Patient

Votre `template` de données de 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 goulots d'étranglement

Votre template de données de Parcours Patient

Votre template de données de 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 goulots d'étranglement

Votre `template` de données de Parcours Patient

Votre `template` de données de Parcours Patient