> Amélioration continue des processus > Parcours du patient > Veradigm (Allscripts) > Modèle de données

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

Veradigm (Allscripts)

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

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

Ce modèle propose une méthode structurée pour recueillir les données nécessaires à l’analyse du parcours de vos patients. Il présente les attributs et les activités essentiels à suivre, ainsi que des conseils pratiques pour extraire ces informations de votre système source. Utilisez cette ressource pour préparer vos données à une analyse complète en Process Mining.

Attributs recommandés pour une analyse complète
Activités clés à suivre pour découvrir le processus avec précision
Conseils pratiques pour extraire les données de votre système

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 du patient

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser le parcours du patient de manière complète.

3 Obligatoire 8 Recommandé 8 Facultatif

	Nom	Description
	Épisode de soins du patient PatientEpisodeId	Identifiant unique de la visite ou de la consultation du patient.
Description L’épisode de soins du patient sert d’identifiant de cas principal. Il regroupe tous les événements liés au parcours de soins d’un patient pour une affection ou une période de soins donnée. Il offre ainsi une vue intégrée des phases de diagnostic, de traitement et de rétablissement, en reliant les interactions avec les différents services. Dans les systèmes Veradigm (Allscripts), comme Sunrise ou Paragon, il correspond généralement à l’identifiant de visite (Visit ID) ou au numéro de consultation (Encounter Number). Pourquoi est-ce important ? Il s’agit de la clé fondamentale du Process Mining, qui permet de reconstituer le parcours patient de bout en bout. Où trouver ces données Se trouve probablement dans l’en-tête des tables Visit ou Encounter (par exemple, VISIT_ID, ENCOUNTER_ID). Consultez la documentation Veradigm (Allscripts). Exemples EP-2023-998877VIS-10029384100029384ENC-554433
	Horodatage de l’événement EventDateTime	Date et heure exactes auxquelles l’activité a eu lieu.
Description Indique le moment où l’activité s’est produite. Cet horodatage est essentiel pour calculer les temps de cycle et les durées, ainsi que pour ordonner correctement les événements. Dans les données de santé, une précision à la minute est indispensable pour analyser avec exactitude le débit de patients. Pourquoi est-ce important ? Permet de calculer tous les KPI liés au temps, notamment le temps de cycle moyen du parcours patient et les temps d’attente. Où trouver ces données Horodatages des transactions dans les tables sources (par exemple, ADT_DATE, ORDER_DATE, RESULT_DATE). Exemples 2023-10-12T08:30:00Z2023-10-12T14:45:22Z2023-10-15T09:00:00Z
	Nom de l’activité ActivityName	Événement clinique ou administratif précis qui a eu lieu.
Description Décrit l’étape réalisée dans le processus, par exemple « Patient enregistré », « Médicament administré » ou « Début de la préparation de la sortie ». Cet attribut distingue les différentes étapes du parcours patient et est indispensable à la découverte des processus et à l’analyse des variantes. Pourquoi est-ce important ? Définit les nœuds de la cartographie des processus. Sans cet attribut, aucun flux de processus ne peut être visualisé. Où trouver ces données Issu de différentes tables transactionnelles : événements ADT, prescriptions, résultats et documentation clinique. Exemples Patient enregistréExamen diagnostique prescritMédicament administréPatient sorti
	Clinicien responsable AttendingProvider	Clinicien principalement responsable du patient pendant l’événement.
Description Identifie le médecin, l’infirmier ou le spécialiste qui réalise l’activité ou qui est responsable du plan de soins. L’analyse de cet attribut aide à comprendre l’utilisation des ressources cliniques et les différences de parcours de soins selon le médecin. Pourquoi est-ce important ? Permet d’analyser les goulots d’étranglement liés aux ressources et de comparer les performances du personnel clinique. Où trouver ces données Tables transactionnelles (par exemple, ORDERing_PROVIDER, ATTENDING_PHYSICIAN_ID). Consultez la documentation Veradigm (Allscripts). Exemples Dr Sarah SmithInfirmier praticien JonesTechnicien en radiologie A
	Code du diagnostic principal PrimaryDiagnosisCode	Code ICD-10 ou SNOMED correspondant à l’affection principale.
Description Motif codé de la visite du patient. Cet attribut sert de filtre à l’outil d’exploration des variantes de parcours thérapeutique. Il permet aux analystes de comparer le cheminement de différentes affections, comme la pneumonie et l’insuffisance cardiaque, dans le système. Pourquoi est-ce important ? Nécessaire pour segmenter les processus selon l’affection clinique et vérifier le respect des protocoles. Où trouver ces données Tables des diagnostics ou des listes de problèmes (généralement avec des colonnes ICD-10). Consultez la documentation Veradigm (Allscripts). Exemples I50.9J18.9E11.9
	Date d’admission AdmissionDate	Date et heure de l’admission officielle du patient.
Description Horodatage marquant le début du séjour hospitalier. Utilisé avec la date de sortie pour calculer la durée moyenne de séjour (ALOS). Pourquoi est-ce important ? Repère essentiel pour calculer l’ALOS et mesurer les retards d’admission. Où trouver ces données Table d’en-tête Visit/Encounter (par exemple, ADMIT_DATE). Consultez la documentation Veradigm (Allscripts). Exemples 2023-10-01T10:00:00Z2023-10-05T14:20:00Z
	Date de sortie DischargeDate	Date et heure de sortie du patient.
Description Horodatage marquant la fin de l’épisode. Il sert à clôturer le cas dans le Process Mining et est indispensable au calcul de la durée moyenne de séjour (DMS) et des réadmissions. Pourquoi est-ce important ? Définit la fin du cycle de processus ; essentiel à l’analyse du débit. Où trouver ces données Table d’en-tête des visites/rencontres (par exemple, DISCH_DATE). Consultez la documentation de Veradigm (Allscripts). Exemples 2023-10-04T11:00:00Z2023-10-10T09:30:00Z
	Destination à la sortie DischargeDisposition	Statut ou lieu où se trouve le patient au moment de sa sortie.
Description Indique où le patient est allé après son séjour à l’hôpital (par exemple, « Domicile », « Établissement de soins infirmiers », « Décès », « Transfert »). Cette information est importante pour analyser les risques de réadmission, car chaque destination correspond à un niveau de risque différent. Pourquoi est-ce important ? Apporte du contexte au Dashboard « Planification de la sortie » et aide à expliquer les écarts de durée moyenne de séjour (DMS). Où trouver ces données Table d’en-tête des visites/rencontres (par exemple, DISCH_DISP). Consultez la documentation de Veradigm (Allscripts). Exemples DomicileTransfert vers un établissement de soins infirmiersDomicile avec services de soins à domicileDépart contre avis médical
	Nom du service DepartmentName	Unité ou service hospitalier où l’activité a eu lieu.
Description Indique le lieu de l’activité, par exemple les urgences, la cardiologie ou la radiologie. Cet attribut est essentiel pour l’analyse des goulots d’étranglement lors des admissions et des transferts, afin de repérer les étapes où les patients restent bloqués lors de leur transfert entre services. Pourquoi est-ce important ? Facilite l’analyse de l’utilisation des ressources et le repérage des goulots d’étranglement dans les services. Où trouver ces données Tables de référence des lieux ou des services associées à la transaction. Consultez la documentation Veradigm (Allscripts). Exemples Service des urgencesICUChirurgie généraleRadiologie
	Numéro de dossier médical du patient (MRN) PatientMrn	Numéro de dossier médical qui identifie le patient de manière unique d’un épisode de soins à l’autre.
Description Le numéro de dossier médical (MRN) ou l’identifiant patient d’entreprise (Enterprise Patient ID). Contrairement à l’identifiant de l’épisode de soins, cet identifiant reste le même pour un patient d’une visite à l’autre. Il est indispensable pour relier plusieurs épisodes et calculer les taux de réadmission. Pourquoi est-ce important ? Indispensable pour calculer le taux de réadmission à 30 jours et repérer les patients qui reviennent. Où trouver ces données Index principal des patients ou tables démographiques (colonnes probables : MRN, PATIENT_ID). Consultez la documentation Veradigm (Allscripts). Exemples MRN-884422P-10022399887766
	Réadmission IsReadmission	Indicateur précisant si cet épisode correspond à une réadmission dans les 30 jours.
Description Attribut booléen calculé. Il renvoie la valeur true si le patient a connu une sortie antérieure dans les 30 jours précédant la date d’admission actuelle. Il alimente le « Suivi du taux de réadmissions évitables ». Pourquoi est-ce important ? Indicateur clé de performance pour la qualité hospitalière et le remboursement, notamment au regard de la réglementation du CMS. Où trouver ces données Calculé dans la couche ETL/de transformation des données à partir de PatientMRN et des dates d’admission et de sortie. Exemples truefalse
	Centre de coûts CostCenter	Code financier associé au service ou au département.
Description Associe l’activité clinique à une unité financière. Cela permet d’analyser le « Coût de l’activité » et les résultats financiers généraux des différents départements. Pourquoi est-ce important ? Relie l’analyse des processus opérationnels à leur impact financier. Où trouver ces données Tables des départements ou des tarifs. Consultez la documentation de Veradigm (Allscripts). Exemples CC-1020CC-Rad-01Emergency-001
	Date du rendez-vous de suivi FollowUpAppointmentDate	Date du rendez-vous de suivi prévu.
Description Utilisé pour calculer le « Taux de rendez-vous de suivi planifiés ». Si ce champ est renseigné, un rendez-vous de suivi a été planifié. S’il est vide ou nul, aucun rendez-vous n’a été planifié. Pourquoi est-ce important ? Mesure directement l’indicateur clé de performance (KPI) « Respect du suivi des soins ». Où trouver ces données Système de planification ou table des rendez-vous à venir associée au patient. Consultez la documentation de Veradigm (Allscripts). Exemples 2023-11-15T14:00:00Znull
	Délai de traitement des examens diagnostiques DiagnosticTurnaroundTime	Durée entre la prescription d’un examen et l’obtention de son résultat.
Description Durée calculée entre « Examen diagnostique prescrit » et « Diagnostic confirmé » (ou réception du résultat). Utilisée dans la « Vue d’ensemble des délais de traitement des examens diagnostiques ». Pourquoi est-ce important ? Des délais de traitement élevés prolongent la durée du séjour ; cette métrique met en évidence les retards au laboratoire et en radiologie. Où trouver ces données Calcul : horodatage du résultat - horodatage de la commande. Exemples 2 heures45 minutes1,5 jour
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière extraction ou mise à jour de l’enregistrement.
Description Indique l’actualité des données utilisées pour l’analyse. Ce champ permet de savoir si les données consultées sont en temps réel ou correspondent à un instantané d’une période antérieure. Pourquoi est-ce important ? Garantit la transparence sur le délai de mise à jour des données et facilite les stratégies de chargement incrémentiel. Où trouver ces données Horodatage généré par le système lors de l’exécution du processus ETL ou de l’extraction. Exemples 2023-11-01T23:59:59Z2023-11-02T06:00:00Z
	Identifiant de commande OrderId	Identifiant des commandes spécifiques (analyses, médicaments, actes).
Description Relie l’événement « Commande » à l’événement « Résultat » ou « Administration ». Par exemple, il associe « Examen diagnostique prescrit » à « Examen diagnostique réalisé ». Ce niveau de détail est nécessaire au Dashboard « Délai de traitement des examens diagnostiques ». Pourquoi est-ce important ? Permet de calculer la durée de certaines étapes du processus (par exemple, le délai de traitement des analyses). Où trouver ces données Tables de saisie des commandes (par exemple, ORDER_ID, PLACER_ORDER_NUM). Consultez la documentation de Veradigm (Allscripts). Exemples ORD-998877LAB-112233RX-445566
	Nom du médicament MedicationName	Nom du médicament prescrit ou administré.
Description Utilisé spécifiquement pour le Dashboard « Écarts dans les horaires d’administration des médicaments ». Il aide à repérer les retards d’administration de certains médicaments (par exemple, les antibiotiques ou les antalgiques). Pourquoi est-ce important ? Essentiel à l’analyse de la sécurité des soins et à l’optimisation des processus pharmaceutiques. Où trouver ces données Dossier d’administration des médicaments (MAR) ou commandes de la pharmacie. Consultez la documentation de Veradigm (Allscripts). Exemples AmoxicillineHéparineSulfate de morphine
	Respect du protocole IsProtocolCompliant	Indicateur précisant si le cas a suivi le parcours de soins standard.
Description Attribut calculé qui vérifie si certaines activités obligatoires (par exemple, « Constantes relevées » avant « Médicament administré ») ont eu lieu dans le bon ordre. Il alimente le Dashboard « Respect des protocoles de soins ». Pourquoi est-ce important ? Permet de détecter automatiquement les écarts de conformité, sans examen manuel du dossier. Où trouver ces données Calculé dans l’outil de Process Mining ou dans l’ETL, à partir de la séquence des activités. Exemples truefalse
	Système source SourceSystem	Nom du système d’où proviennent les données.
Description Identifie l’instance logicielle qui fournit les données, par exemple « Veradigm Sunrise » ou « Veradigm TouchWorks ». Cet attribut est particulièrement important dans les environnements hospitaliers multiples ou lors du regroupement de données issues de services de soins aigus et ambulatoires. Pourquoi est-ce important ? Assure la traçabilité et le suivi de l’origine des données, ce qui facilite la résolution des problèmes de qualité des données. Où trouver ces données Renseigné en dur pendant le processus ETL ou extrait des tables de métadonnées du système. Exemples Veradigm SunriseAllscripts PMVeradigm TouchWorks

Obligatoire Recommandé Facultatif

Activités du parcours du patient

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir avec précision le processus de prise en charge du patient.

6 Recommandé 7 Facultatif

	Activité	Description
	Début de la préparation de la sortie	Correspond au début officiel de la préparation de la sortie du patient. L’événement peut être déduit de la création d’un document de préparation de sortie, de la saisie d’une prescription de sortie ou de la réalisation d’une évaluation spécifique.
Pourquoi est-ce important ? Cette activité sert de point de départ pour mesurer l’efficacité du processus de sortie. Une préparation commencée tôt est souvent associée à une baisse des réadmissions. Où trouver ces données Déduite de l’horodatage de création d’une note de préparation de sortie, d’un ensemble de prescriptions de sortie ou d’un formulaire d’évaluation spécifique dans Veradigm. Données à recueillir Repérez l’horodatage de création du premier document ou de la première prescription liée à la sortie pour la consultation du patient. Type d’événement inferred
	Diagnostic confirmé	Cette activité indique qu’un clinicien a officiellement consigné un diagnostic dans le dossier du patient. Elle peut être enregistrée lorsqu’un code de diagnostic est ajouté à la liste des problèmes ou lorsqu’une note clinique contenant le diagnostic est signée.
Pourquoi est-ce important ? La confirmation du diagnostic marque un tournant qui détermine la suite du traitement. Elle permet d’analyser les différences de parcours thérapeutique selon les diagnostics. Où trouver ces données À rechercher dans la liste des problèmes du patient, les diagnostics associés à la consultation ou la documentation clinique. L’événement peut être déduit de l’horodatage auquel le code du diagnostic principal est saisi et finalisé pour la consultation. Données à recueillir Utilisez l’horodatage de création ou de mise à jour de l’entrée du diagnostic principal pour l’épisode de soins concerné. Type d’événement inferred
	Évaluation initiale terminée	Indique que la première évaluation clinique par un infirmier ou un médecin, par exemple le triage ou l’accueil initial, est terminée. Elle est souvent enregistrée lorsqu’un formulaire ou une note clinique, comme « Nursing Initial Assessment », est signé et finalisé dans le dossier médical électronique.
Pourquoi est-ce important ? Cette activité constitue une étape précoce importante. Le temps écoulé entre l’inscription et cette évaluation permet de repérer d’éventuels retards dans l’accueil du patient et les premiers soins. Où trouver ces données Déduite de l’horodatage de finalisation ou de signature des formulaires d’évaluation initiale ou des notes cliniques dans les modules de documentation clinique de Veradigm. Données à recueillir Repérez l’horodatage auquel le statut de la note ou du formulaire d’évaluation initiale passe à « completed » ou « signed ». Type d’événement inferred
	Patient enregistré	Marque le début officiel de l’épisode de soins, lorsque les informations du patient sont saisies dans Veradigm. Cet événement est généralement enregistré explicitement à la fin du flux de travail d’inscription, lorsqu’un utilisateur crée un nouveau dossier de consultation avec un identifiant unique et un horodatage.
Pourquoi est-ce important ? Il s’agit de l’activité de départ principale du parcours patient. Elle est indispensable pour calculer le temps de cycle global du processus, la durée du séjour et le débit de patients. Où trouver ces données Cet événement est enregistré dans le module d’inscription des patients ou dans le module ADT (Admission, Discharge, Transfer). Recherchez l’horodatage de création du dossier de consultation ou de visite du patient. Données à recueillir Horodatage de création de l’enregistrement dans la table des consultations ou des inscriptions des patients. Type d’événement explicit
	Patient sorti	Marque la fin officielle de l’épisode d’hospitalisation, lorsque le patient quitte officiellement l’établissement. Cet événement clé est enregistré explicitement par le système ADT, qui met à jour le statut de la consultation du patient en « discharged ».
Pourquoi est-ce important ? Il s’agit de l’activité de fin principale de la plupart des parcours patients. Elle est indispensable pour calculer la durée moyenne de séjour (ALOS) et le temps de cycle global du processus. Où trouver ces données Enregistré explicitement dans le module ADT. Le dossier de consultation du patient comporte un horodatage de sortie et une destination. Données à recueillir Utilisez l’horodatage de sortie du dossier principal de consultation ou de visite du patient. Type d’événement explicit
	Plan de traitement établi	Correspond à la formalisation du plan de traitement du patient par l’équipe clinique. L’événement est souvent enregistré lorsqu’un document « Plan of Care » ou un ensemble de prescriptions thérapeutiques initiales est créé et signé dans le dossier médical électronique.
Pourquoi est-ce important ? Cette étape marque le début de la phase de traitement actif. Elle sert de référence pour mesurer le respect des protocoles de soins et le délai avant la première intervention thérapeutique, comme l’administration d’un médicament. Où trouver ces données Déduite de l’horodatage de signature d’un formulaire « Plan of Care » ou de l’horodatage de création du premier ensemble important de prescriptions thérapeutiques après le diagnostic. Données à recueillir Repérez l’horodatage auquel le document « Plan of Care » est finalisé ou signé par le clinicien responsable. Type d’événement inferred
	Constantes vitales enregistrées	Cette activité se produit chaque fois que les constantes vitales du patient, comme la fréquence cardiaque, la tension artérielle et la température, sont enregistrées. Il s’agit d’un événement explicite consigné dans la documentation clinique ou dans la section dédiée aux constantes vitales du tableau de suivi du dossier médical électronique.
Pourquoi est-ce important ? L’enregistrement fréquent des constantes vitales témoigne d’un suivi actif du patient. La fréquence et le moment des relevés peuvent être analysés pour vérifier le respect des protocoles de surveillance. Où trouver ces données Enregistré dans le référentiel de données cliniques ou dans les tables du tableau de suivi où sont stockées les constantes vitales. Chaque entrée comporte un horodatage. Données à recueillir Extrayez les horodatages des données du tableau de suivi des constantes vitales pour la consultation du patient. Type d’événement explicit
	Examen diagnostique prescrit	Cet événement se produit lorsqu’un clinicien prescrit un examen diagnostique, par exemple une analyse de laboratoire ou un examen d’imagerie. Il est enregistré explicitement dans le système de saisie informatisée des prescriptions médicales (CPOE) de Veradigm.
Pourquoi est-ce important ? Cette étape marque le début du sous-processus de diagnostic. Elle sert de point de départ pour mesurer les délais de réalisation des examens et repérer les retards de prescription. Où trouver ces données Enregistré dans le module des prescriptions ou dans les journaux du système CPOE. Chaque prescription comporte un horodatage indiquant quand elle a été passée. Données à recueillir Extrayez l’horodatage de création des enregistrements de prescription pour les examens diagnostiques concernés. Type d’événement explicit
	Examen diagnostique terminé	Indique que les résultats d’un examen diagnostique sont finalisés et disponibles dans le dossier du patient. Cet événement est généralement déduit du changement de statut de la prescription initiale, qui passe de « active » ou « in-progress » à « completed » ou « resulted ».
Pourquoi est-ce important ? Cette activité constitue une étape importante pour mesurer les délais de réalisation des examens diagnostiques. Les retards entre la prescription et la réalisation peuvent allonger considérablement le délai avant le diagnostic. Où trouver ces données Déduite du champ de statut de la prescription dans le module correspondant ou des horodatages du module de résultats associé, comme le LIS ou le RIS. Données à recueillir Repérez l’horodatage auquel le statut de la prescription passe à un état final, comme « Completed » ou « Resulted ». Type d’événement inferred
	Intervention réalisée	Indique qu’une intervention clinique ou chirurgicale est terminée. L’événement est généralement enregistré lorsqu’un clinicien signe le compte rendu de l’intervention ou lorsque le statut de la prescription correspondante passe à « completed » dans le système.
Pourquoi est-ce important ? Les interventions constituent des étapes importantes dans de nombreux parcours patients. L’analyse de leur calendrier permet de mieux comprendre l’utilisation des ressources et l’efficacité de la planification. Où trouver ces données Déduite de l’horodatage de signature du compte rendu d’intervention dans le module de documentation clinique ou de l’horodatage de fin dans le module des prescriptions. Données à recueillir Utilisez l’horodatage de fin de la prescription d’intervention ou l’horodatage de signature de la documentation correspondante. Type d’événement inferred
	Médicament administré	Cet événement est enregistré lorsqu’un infirmier ou un clinicien consigne l’administration d’un médicament au patient. Il figure dans le registre d’administration des médicaments (MAR) ou le module eMAR, qui indique l’heure exacte de l’administration.
Pourquoi est-ce important ? Le suivi de l’administration des médicaments est essentiel pour analyser la rapidité du traitement et le respect des prescriptions. Le délai entre la prescription et l’administration permet de repérer les retards dans le processus de délivrance des médicaments. Où trouver ces données Enregistré explicitement dans le module eMAR (registre électronique d’administration des médicaments). Chaque administration comporte un horodatage, le nom du médicament et la dose. Données à recueillir Extrayez les horodatages de la table eMAR pour chaque administration de médicament associée à la consultation du patient. Type d’événement explicit
	Suivi programmé	Cette activité correspond à la prise de rendez-vous de suivi après la sortie du patient. Elle est enregistrée dans le module de planification lorsqu’un rendez-vous associé à la consultation ayant donné lieu à la sortie est réservé.
Pourquoi est-ce important ? La programmation des soins de suivi est essentielle pour assurer la continuité des soins et réduire les réadmissions. Cette activité permet de mesurer le respect des protocoles après la sortie. Où trouver ces données Enregistré dans le module de planification des rendez-vous. Recherchez l’horodatage de création d’un nouveau rendez-vous pour le patient, après sa date de sortie. Données à recueillir Repérez l’horodatage de création d’un rendez-vous associé au patient dans le système de planification. Type d’événement explicit
	Transfert vers un service	Cet événement marque le transfert physique du patient d’un service ou d’une unité de soins à un autre, par exemple des urgences vers un service d’hospitalisation. Il est enregistré par le système ADT de Veradigm.
Pourquoi est-ce important ? Les transferts de patients sont des étapes où des goulots d’étranglement et des retards peuvent survenir. L’analyse de leur durée et de leur fréquence aide à optimiser le parcours des patients et la répartition des ressources entre les services. Où trouver ces données Enregistré explicitement dans le module ADT. Chaque transfert indique le patient, le lieu de départ et le lieu d’arrivée, ainsi qu’un horodatage. Données à recueillir Extrayez du système ADT les journaux d’événements correspondant aux déplacements des patients. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Veradigm (Allscripts)

Étapes

Repérez le canal d’interface cible : Connectez-vous à la console de gestion d’Allscripts Interface Engine (AIE). Repérez le canal d’interface principal qui traite les messages entrants du DME (généralement nommé « EHR_Inbound » ou de façon similaire). Vérifiez qu’il prend en charge les types de messages ADT, SIU, ORM, ORU, RAS et DFT, afin de couvrir l’ensemble des activités du parcours patient.
Créez un canal de transfert ou d’export : Créez un canal de destination nommé « ProcessMining_Export ». Définissez le type de sortie sur « File Writer ». Ce canal recevra une copie des messages du canal source et les convertira en fichier plat (CSV) pour ProcessMind.
Configurez le routage des messages : Dans les règles de routage AIE, configurez une règle de copie ou de routage pour envoyer les messages du canal DME principal vers le nouveau canal « ProcessMining_Export ». Filtrez le routage afin de ne conserver que les types de messages nécessaires : ADT (inscription/transfert), SIU (planification), ORM (commandes), ORU (résultats/constantes), RAS (médicaments) et DFT (facturation/interventions).
Définissez la logique de transformation : Dans le canal « ProcessMining_Export », ouvrez l’éditeur de transformation ou de script. Vous devez y implémenter un script d’analyse (voir la section « query » ci-dessous) qui lit les segments HL7 bruts et associe des événements déclencheurs et des codes de statut précis aux noms d’activité standard requis, par exemple en associant « ADT^A01 » à « Patient Registered ».
Associez les attributs aux champs HL7 : Vérifiez que le script extrait « PatientEpisodeId » du segment PV1-19 (numéro de visite) et « PatientMrn » du champ PID-3. Associez « EventDateTime » à MSH-7 ou EVN-2. Extrayez les informations cliniques, comme « DepartmentName » depuis PV1-3 et « AttendingProvider » depuis PV1-7.
Définissez les paramètres du fichier de sortie : Configurez les paramètres de File Writer. Définissez le répertoire de sortie sur un chemin réseau sécurisé. Choisissez une convention de nommage des fichiers, par exemple EventLog_YYYYMMDD_HH.csv. Réglez le mode de fichier sur « Append » pour ajouter continuellement des lignes au journal.
Gérez les délimiteurs et les caractères d’échappement : Dans le script, veillez à nettoyer les champs texte, comme le diagnostic ou le nom du service, en supprimant les virgules et les retours à la ligne qui pourraient perturber la structure CSV.
Activez et testez le canal : Démarrez le canal « ProcessMining_Export ». Déclenchez un événement de test dans l’environnement de test Veradigm, par exemple en inscrivant un patient fictif. Vérifiez qu’une nouvelle ligne apparaît dans le fichier CSV avec le nom d’activité et l’horodatage corrects.
Configurez la rotation des journaux : Définissez une rotation, par exemple chaque jour à minuit, pour fermer le fichier CSV en cours et en créer un nouveau. Vous obtiendrez ainsi des fichiers de taille raisonnable à importer.
Rejouez les données historiques (facultatif) : Si vous avez besoin de données historiques, utilisez l’outil « Message Browser » ou « Log Replay » d’AIE pour renvoyer les journaux HL7 archivés des 3 à 6 derniers mois via le canal « ProcessMining_Export ». Surveillez les performances du système pour éviter tout ralentissement.
Récupérez et mettez en forme les fichiers : Accédez au répertoire de sortie, récupérez les fichiers CSV générés et vérifiez que leurs en-têtes correspondent aux exigences. Regroupez les fichiers quotidiens si nécessaire.
Importez les données dans ProcessMind : Importez le jeu de données final dans ProcessMind et associez « PatientEpisodeId » à l’ID de cas, « ActivityName » à l’activité et « EventDateTime » à l’horodatage.

Configuration

Type de canal : File Writer / File System Output
Événements déclencheurs : ADT^A01, ADT^A03, ADT^A04, ADT^A08, SIU^S12, ORM^O01, ORU^R01, RAS^O17, DFT^P03
Encodage du fichier : UTF-8 (important pour les caractères spéciaux dans les noms et les diagnostics)
Délimiteur : virgule (,) ou barre verticale (|)
Format de date : ISO 8601 (YYYY-MM-DDTHH:MM:SS), recommandé pour la conversion des horodatages HL7
Rotation des journaux : quotidienne ou lorsque la taille du fichier dépasse 100 Mo
Mode d’écriture : Append (ne pas écraser)
Performances : veillez à ce que le script de transformation reste léger pour éviter la mise en file d’attente ou l’accumulation des messages dans le moteur.

Exemple de requête config

// AIE Transformation Script (Pseudo-code for Config)
// Objective: Parse HL7 message and append line to CSV
// Output Columns: PatientEpisodeId, ActivityName, EventDateTime, PatientMrn, AttendingProvider, DepartmentName, PrimaryDiagnosisCode

// 1. Initialize Variables
var msgType = HL7.GetField("MSH-9-1") + "^" + HL7.GetField("MSH-9-2");
var visitNumber = HL7.GetField("PV1-19");
var mrn = HL7.GetField("PID-3");
var eventTime = HL7.GetField("MSH-7"); // Or EVN-2
var provider = HL7.GetField("PV1-7");
var dept = HL7.GetField("PV1-3");
var diagnosis = HL7.GetField("DG1-3"); // For Diagnosis events
var orderStatus = HL7.GetField("ORC-5");
var resultStatus = HL7.GetField("OBR-25");
var activityName = "";

// 2. Map Message Types to Activities
// Registration & Admission
if (msgType == "ADT^A04" || msgType == "ADT^A01") {
    activityName = "Patient Registered";
}
else if (msgType == "ADT^A02") {
    activityName = "Transfer to Department";
}
else if (msgType == "ADT^A03") {
    activityName = "Patient Discharged";
}
// Scheduling
else if (msgType == "SIU^S12") {
    activityName = "Follow-up Scheduled";
}
// Orders (Diagnostics, Care Plans, Discharge Planning)
else if (msgType == "ORM^O01") {
    var orderControl = HL7.GetField("ORC-1");
    var orderType = HL7.GetField("OBR-4"); // Check for specific service codes
    
    if (orderControl == "NW") { // New Order
        if (orderType.Contains("LAB") || orderType.Contains("RAD")) {
            activityName = "Diagnostic Test Ordered";
        }
        else if (orderType.Contains("DISCHARGE")) {
            activityName = "Discharge Planning Initiated";
        }
        else if (orderType.Contains("CARE_PLAN")) {
            activityName = "Treatment Plan Created";
        }
    }
}
// Results & Vitals
else if (msgType == "ORU^R01") {
    // Check if it is Vitals or Lab Result based on OBX codes or sending app
    var observationId = HL7.GetField("OBX-3"); 
    if (observationId.Contains("VITALS")) {
        activityName = "Vitals Recorded";
    } else {
        if (resultStatus == "F" || resultStatus == "C") {
            activityName = "Diagnostic Test Completed";
        }
    }
    
    // Initial Assessment Check (often a specific doc type in ORU or MDM)
    if (observationId.Contains("INITIAL_ASSESS")) {
        activityName = "Initial Assessment Completed";
    }
}
// Medication Administration (RAS)
else if (msgType == "RAS^O17") {
    activityName = "Medication Administered";
}
// Billing/Procedures (DFT)
else if (msgType == "DFT^P03") {
    activityName = "Procedure Performed";
}
// Diagnosis Updates (Often in ADT or DFT, logic depends on config)
else if (msgType == "ADT^A08" && diagnosis != "") {
    // Check if diagnosis segment is new/updated
    activityName = "Diagnosis Confirmed";
}

// 3. Write to File if Activity Identified
if (activityName != "" && visitNumber != "") {
    // Format Date to ISO
    var formattedDate = FormatDate(eventTime, "yyyy-MM-dd HH:mm:ss");
    
    // Construct CSV Line
    var csvLine = visitNumber + "," + 
                  activityName + "," + 
                  formattedDate + "," + 
                  mrn + "," + 
                  provider + "," + 
                  dept + "," + 
                  diagnosis;
                  
    File.WriteLine("[Configured_Output_Path]\\PatientJourneyLog.csv", csvLine);
}

Étapes

Prérequis et accès : Vérifiez que vous disposez d’identifiants valides pour l’API Veradigm (Allscripts) Unity. Vous aurez besoin d’un Appname (nom de l’application) autorisé pour votre organisation, ainsi que d’un UserID et d’un Password valides, ou d’un jeton d’authentification. Vérifiez que le compte utilisateur peut accéder aux domaines cliniques (rencontres, commandes, résultats, constantes et problèmes).
Configuration de l’environnement : Installez Python 3.8 ou une version ultérieure. Installez les bibliothèques nécessaires avec pip : pip install requests pandas. Elles serviront à envoyer des requêtes HTTP à l’API Unity et à manipuler les données obtenues.
Configuration : Ouvrez le script Python fourni. Repérez la section CONFIGURATION au début du fichier. Modifiez API_URL pour indiquer le point de terminaison de votre environnement Unity, par exemple unity.veradigm.com ou une passerelle interne. Remplacez les identifiants génériques ([YourAppName], [YourUserID], etc.) par vos propres identifiants. Définissez START_DATE et END_DATE pour la période d’analyse souhaitée.
Fonctionnement du script : Le script commence par s’authentifier auprès de l’API pour obtenir un jeton de sécurité. Il appelle ensuite GetEncounterInfo afin de récupérer tous les épisodes de soins des patients pour la période définie. Cette liste de rencontres sert de point de départ central à l’extraction.
Boucle d’extraction des activités : Pour chaque EncounterID repéré, le script envoie des appels complémentaires à des points de terminaison spécialisés. Il appelle GetOrders pour repérer les examens diagnostiques et les interventions, GetResults pour identifier les examens terminés et GetVitals pour récupérer les relevés des constantes. Il appelle GetPatientProblems pour obtenir les diagnostics confirmés et parcourt les notes cliniques à la recherche des évaluations et des plans de traitement.
Transformation des données : À mesure que l’API renvoie des données JSON brutes, le script analyse certains champs et les associe au schéma ProcessMind. Par exemple, OrderDateTime est associé à EventDateTime pour l’activité « Diagnostic Test Ordered ». Le script applique systématiquement PatientEpisodeId (ID de rencontre) à tous les enregistrements associés.
Gestion des événements ADT et des transferts : La logique du script vérifie l’historique des emplacements de la rencontre, s’il est disponible via des appels complémentaires Audit ou ADT, ou déduit les transferts à partir des changements de service consignés dans la documentation clinique afin de générer des événements « Transfer to Department ».
Logique de suivi : Après le traitement de la rencontre, le script interroge GetSchedule pour le même PatientID et recherche les rendez-vous prévus après DischargeDate, afin de générer l’activité « Follow-up Scheduled ».
Validation : Le script comprend une étape de validation locale qui affiche dans la console le nombre de lignes pour chaque type d’activité. Vérifiez qu’aucun type d’activité n’est absent, sauf si cela est attendu.
Export : Le jeu de données final est regroupé dans un DataFrame Pandas. Le script calcule les attributs dérivés, comme LengthOfStay et IsReadmission, après avoir trié les données par patient et par heure. Il exporte ensuite le journal d’événements nettoyé dans un fichier CSV nommé veradigm_patient_journey_log.csv.
Vérification finale : Ouvrez le fichier CSV généré. Vérifiez que les dates sont au format ISO 8601 (YYYY-MM-DD HH:MM:SS) et que les champs texte, comme ActivityName, ne contiennent pas de caractères utilisés comme délimiteurs.
Importation : Importez le fichier CSV dans ProcessMind. Associez PatientEpisodeId à l’ID de cas, ActivityName à l’activité et EventDateTime à l’horodatage.

Configuration

API_URL : URL de base des services de l’API Unity. Elle varie selon l’installation du client, sur site ou dans le cloud. Vérifiez que le protocole (https) est correct.
Appname : Identifiant unique de l’application enregistrée auprès de Veradigm/Allscripts. Il détermine l’étendue des données accessibles.
Période : Une période d’extraction de 3 à 6 mois est recommandée. Les périodes plus longues peuvent entraîner un délai d’expiration. Si le volume est important, envisagez de procéder par lots mensuels.
Délais d’expiration : Le délai par défaut des appels API est de 30 secondes. Augmentez-le si le système DME est fortement sollicité.
Traitement par lots : Le script traite les rencontres une par une. Pour les systèmes à fort volume, il peut être nécessaire de le modifier pour récupérer les données en masse, si les points de terminaison le permettent, ou d’exécuter plusieurs fils en parallèle.
Logique d’association : Le script associe OrderType aux activités. Vérifiez que les codes de type de commande propres à votre système, par exemple « Lab » ou « Rad », correspondent à la logique de la fonction process_orders.

Exemple de requête python

import requests
import pandas as pd
import json
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
API_URL = class="hl-string">"https://unity.veradigm.com/[YourEnvironment]/unity/unityservice.svc/json"
APP_NAME = class="hl-string">"[YourAppName]"
USER_ID = class="hl-string">"[YourUserID]"
PASSWORD = class="hl-string">"[YourPassword]"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
OUTPUT_FILE = class="hl-string">"veradigm_patient_journey_log.csv"

class=class="hl-string">"hl-comment"># Global Session Token
TOKEN = None

def get_security_token():
    class="hl-string">"""Authenticate and retrieve security token."""
    payload = {
        class="hl-string">"Action": class="hl-string">"GetToken",
        class="hl-string">"Appname": APP_NAME,
        class="hl-string">"Username": USER_ID,
        class="hl-string">"Password": PASSWORD
    }
    try:
        response = requests.post(API_URL, json=payload)
        response.raise_for_status()
        data = response.json()
        class=class="hl-string">"hl-comment"># Depending on Unity version, token might be in body or header. Assuming body here.
        return data[0][class="hl-string">'Token'] if isinstance(data, list) else data.get(class="hl-string">'Token')
    except Exception as e:
        print(fclass="hl-string">"Authentication failed: {e}")
        return None

def make_unity_request(action, params):
    class="hl-string">"""Wrapper for Unity API calls."""
    payload = {
        class="hl-string">"Action": action,
        class="hl-string">"Appname": APP_NAME,
        class="hl-string">"Token": TOKEN
    }
    payload.update(params)
    
    try:
        response = requests.post(API_URL, json=payload, timeout=30)
        response.raise_for_status()
        class=class="hl-string">"hl-comment"># Unity often returns a list of dictionaries
        return response.json()
    except Exception as e:
        print(fclass="hl-string">"API Call Error ({action}): {e}")
        return []

def extract_patient_journey():
    global TOKEN
    TOKEN = get_security_token()
    if not TOKEN:
        return

    print(class="hl-string">"Token acquired. Starting extraction...")
    
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Get Encounters within Date Range
    class=class="hl-string">"hl-comment"># Using GetEncounterInfo or similar search action
    encounters = make_unity_request(class="hl-string">"GetEncounterInfo", {
        class="hl-string">"StartEncounterDate": START_DATE,
        class="hl-string">"EndEncounterDate": END_DATE
    })

    print(fclass="hl-string">"Found {len(encounters)} encounters. Processing details...")

    for enc in encounters:
        try:
            class=class="hl-string">"hl-comment"># Basic Encounter Data
            episode_id = str(enc.get(class="hl-string">'EncounterID'))
            patient_id = enc.get(class="hl-string">'PatientID')
            mrn = enc.get(class="hl-string">'MRN', class="hl-string">'')
            admit_time = enc.get(class="hl-string">'EncounterDate') class=class="hl-string">"hl-comment"># ISO string expected
            discharge_time = enc.get(class="hl-string">'DischargeDate')
            dept_name = enc.get(class="hl-string">'Department', class="hl-string">'General')
            attending = enc.get(class="hl-string">'ProviderName', class="hl-string">'Unknown')
            
            class=class="hl-string">"hl-comment"># --- Activity: Patient Registered ---
            if admit_time:
                event_log.append({
                    class="hl-string">"PatientEpisodeId": episode_id,
                    class="hl-string">"ActivityName": class="hl-string">"Patient Registered",
                    class="hl-string">"EventDateTime": admit_time,
                    class="hl-string">"PatientMrn": mrn,
                    class="hl-string">"AttendingProvider": attending,
                    class="hl-string">"DepartmentName": dept_name,
                    class="hl-string">"AdmissionDate": admit_time,
                    class="hl-string">"DischargeDate": discharge_time
                })

            class=class="hl-string">"hl-comment"># --- Activity: Patient Discharged ---
            if discharge_time:
                 event_log.append({
                    class="hl-string">"PatientEpisodeId": episode_id,
                    class="hl-string">"ActivityName": class="hl-string">"Patient Discharged",
                    class="hl-string">"EventDateTime": discharge_time,
                    class="hl-string">"PatientMrn": mrn,
                    class="hl-string">"AttendingProvider": attending,
                    class="hl-string">"DepartmentName": dept_name,
                    class="hl-string">"AdmissionDate": admit_time,
                    class="hl-string">"DischargeDate": discharge_time
                })

            class=class="hl-string">"hl-comment"># 2. Get Orders (Labs, Procedures, Consults)
            orders = make_unity_request(class="hl-string">"GetOrders", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for order in orders:
                order_time = order.get(class="hl-string">'OrderDate')
                order_type = order.get(class="hl-string">'OrderType', class="hl-string">'').lower()
                order_name = order.get(class="hl-string">'OrderName', class="hl-string">'Unknown Order')
                
                class=class="hl-string">"hl-comment"># --- Activity: Diagnostic Test Ordered ---
                if class="hl-string">'lab' in order_type or class="hl-string">'imaging' in order_type or class="hl-string">'radiology' in order_type:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnostic Test Ordered",
                        class="hl-string">"EventDateTime": order_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_OrderName": order_name
                    })

                class=class="hl-string">"hl-comment"># --- Activity: Procedure Performed ---
                class=class="hl-string">"hl-comment"># Often procedures are orders with status completed or specific types
                if class="hl-string">'procedure' in order_type and order.get(class="hl-string">'Status') == class="hl-string">'Completed':
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Procedure Performed",
                        class="hl-string">"EventDateTime": order.get(class="hl-string">'CompletionDate', order_time),
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_ProcedureName": order_name
                    })
                    
                class=class="hl-string">"hl-comment"># --- Activity: Discharge Planning Initiated ---
                if class="hl-string">'discharge' in order_name.lower():
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Discharge Planning Initiated",
                        class="hl-string">"EventDateTime": order_time,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 3. Get Results (Lab completion)
            results = make_unity_request(class="hl-string">"GetResults", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for res in results:
                result_time = res.get(class="hl-string">'ResultDate')
                if result_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Diagnostic Test Completed ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnostic Test Completed",
                        class="hl-string">"EventDateTime": result_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_ResultName": res.get(class="hl-string">'TestName', class="hl-string">'Unknown Test')
                    })

            class=class="hl-string">"hl-comment"># 4. Get Problems (Diagnosis)
            problems = make_unity_request(class="hl-string">"GetPatientProblems", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for prob in problems:
                onset_date = prob.get(class="hl-string">'OnsetDate') or prob.get(class="hl-string">'DateEntered')
                if onset_date:
                     class=class="hl-string">"hl-comment"># --- Activity: Diagnosis Confirmed ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnosis Confirmed",
                        class="hl-string">"EventDateTime": onset_date,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"PrimaryDiagnosisCode": prob.get(class="hl-string">'ICD10', class="hl-string">''),
                        class="hl-string">"Attribute_DiagnosisName": prob.get(class="hl-string">'ProblemDescription', class="hl-string">'')
                    })

            class=class="hl-string">"hl-comment"># 5. Get Vitals
            vitals = make_unity_request(class="hl-string">"GetVitals", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for vit in vitals:
                taken_time = vit.get(class="hl-string">'DateTaken')
                if taken_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Vitals Recorded ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Vitals Recorded",
                        class="hl-string">"EventDateTime": taken_time,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 6. Get Clinical Notes (Assessments, Plans)
            class=class="hl-string">"hl-comment"># Sometimes accessed via GetNoteInfo or GetChart
            notes = make_unity_request(class="hl-string">"GetNoteInfo", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for note in notes:
                note_date = note.get(class="hl-string">'NoteDate')
                note_title = note.get(class="hl-string">'DocumentType', class="hl-string">'').lower()
                
                class=class="hl-string">"hl-comment"># --- Activity: Initial Assessment Completed ---
                if class="hl-string">'initial' in note_title or class="hl-string">'assessment' in note_title:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Initial Assessment Completed",
                        class="hl-string">"EventDateTime": note_date,
                        class="hl-string">"PatientMrn": mrn
                    })
                
                class=class="hl-string">"hl-comment"># --- Activity: Treatment Plan Created ---
                if class="hl-string">'plan' in note_title or class="hl-string">'care' in note_title:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Treatment Plan Created",
                        class="hl-string">"EventDateTime": note_date,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 7. Med Administration (GetMedicationAdministration or inferred from Med History)
            meds = make_unity_request(class="hl-string">"GetMedicationAdministration", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for med in meds:
                admin_time = med.get(class="hl-string">'AdministrationDate')
                if admin_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Medication Administered ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Medication Administered",
                        class="hl-string">"EventDateTime": admin_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_MedicationName": med.get(class="hl-string">'MedicationName', class="hl-string">'')
                    })

            class=class="hl-string">"hl-comment"># 8. Transfer Events (Infer from ADT or Audit log)
            class=class="hl-string">"hl-comment"># Simulating transfer extraction via AuditLog for Location changes
            audit_logs = make_unity_request(class="hl-string">"GetAuditLog", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for log in audit_logs:
                if class="hl-string">"Transfer" in log.get(class="hl-string">'EventName', class="hl-string">'') or class="hl-string">"Location Change" in log.get(class="hl-string">'EventName', class="hl-string">''):
                     class=class="hl-string">"hl-comment"># --- Activity: Transfer to Department ---
                     event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Transfer to Department",
                        class="hl-string">"EventDateTime": log.get(class="hl-string">'EventDate'),
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"DepartmentName": log.get(class="hl-string">'NewValue', class="hl-string">'Unknown Dept')
                     })

            class=class="hl-string">"hl-comment"># 9. Follow-up Scheduled
            if discharge_time:
                future_appts = make_unity_request(class="hl-string">"GetSchedule", {class="hl-string">"PatientID": patient_id, class="hl-string">"StartDate": discharge_time})
                for appt in future_appts:
                    class=class="hl-string">"hl-comment"># --- Activity: Follow-up Scheduled ---
                    class=class="hl-string">"hl-comment"># Note: We want the time the appt was BOOKED, but Unity usually gives ApptDate.
                    class=class="hl-string">"hl-comment"># We will use the creation date of the appt if available, otherwise ApptDate as proxy
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Follow-up Scheduled",
                        class="hl-string">"EventDateTime": appt.get(class="hl-string">'DateBooked', appt.get(class="hl-string">'ApptDate')), 
                        class="hl-string">"PatientMrn": mrn
                    })

        except Exception as e:
            print(fclass="hl-string">"Error processing encounter {enc.get('EncounterID')}: {e}")
            continue

    class=class="hl-string">"hl-comment"># Post-Processing: Create DataFrame
    df = pd.DataFrame(event_log)
    
    class=class="hl-string">"hl-comment"># Helper: Convert strings to datetime
    df[class="hl-string">'EventDateTime'] = pd.to_datetime(df[class="hl-string">'EventDateTime'], errors=class="hl-string">'coerce')
    df = df.dropna(subset=[class="hl-string">'EventDateTime', class="hl-string">'PatientEpisodeId'])
    
    class=class="hl-string">"hl-comment"># Calculate LOS and Readmission
    df[class="hl-string">'AdmissionDate'] = pd.to_datetime(df[class="hl-string">'AdmissionDate'], errors=class="hl-string">'coerce')
    df[class="hl-string">'DischargeDate'] = pd.to_datetime(df[class="hl-string">'DischargeDate'], errors=class="hl-string">'coerce')
    
    class=class="hl-string">"hl-comment"># LOS
    df[class="hl-string">'LengthOfStay'] = (df[class="hl-string">'DischargeDate'] - df[class="hl-string">'AdmissionDate']).dt.days

    class=class="hl-string">"hl-comment"># IsReadmission (Simplified: check if patient had previous discharge within 30 days)
    class=class="hl-string">"hl-comment"># Requires sorting by patient and admission time first
    class=class="hl-string">"hl-comment"># This is complex in a flat event log context, simplified here as placeholder logic
    df[class="hl-string">'IsReadmission'] = False 

    print(fclass="hl-string">"Extraction complete. Rows: {len(df)}")
    df.to_csv(OUTPUT_FILE, index=False)
    print(fclass="hl-string">"Data saved to {OUTPUT_FILE}")

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

Prêt à commencer ?

Commencez dès aujourd’hui à améliorer l’expérience des patients et l’efficacité opérationnelle. Vos données peuvent vous aider à repérer des pistes d’amélioration et à obtenir des résultats concrets.

Retour au guide d’amélioration

Télécharger le modèle

Optimisez dès aujourd’hui les parcours des patients dans Veradigm

Réduisez de 30 % le temps de cycle des patients et améliorez la qualité des soins.

Démarrez votre essai gratuit

Aucune carte bancaire n’est requise. Commencez immédiatement.

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

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

Attributs du parcours du patient

Activités du parcours du patient

Guides d’extraction

Export du journal d’événements du moteur d’interface Allscripts

Étapes

Configuration

Exemple de requête config

Extraction via l’API Veradigm Unity avec Python

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui les parcours des patients dans Veradigm

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

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

Attributs du parcours du patient

Activités du parcours du patient

Guides d’extraction

Export du journal d’événements du moteur d’interface Allscripts

Étapes

Configuration

Exemple de requête config

Extraction via l’API Veradigm Unity avec Python

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui les parcours des patients dans Veradigm

Prêt à commencer ?